From tammy_leino@mentor.com Wed Apr 1 13:27:34 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B543A6C1E for ; Wed, 1 Apr 2009 13:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtf5ZBXbVH6t for ; Wed, 1 Apr 2009 13:27:30 -0700 (PDT) Received: from relay1.mentorg.com (relay1.mentorg.com [192.94.38.131]) by core3.amsl.com (Postfix) with ESMTP id C85903A6AA5 for ; Wed, 1 Apr 2009 13:27:30 -0700 (PDT) Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Lp730-0007cZ-RY from tammy_leino@mentor.com for tcpm@ietf.org; Wed, 01 Apr 2009 13:28:30 -0700 Received: from na2-mail.mgc.mentorg.com ([134.86.114.213]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 13:28:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B308.5E79C0AA" Date: Wed, 1 Apr 2009 14:29:06 -0600 Message-ID: <2F83EB16CD718C43889CBCD31ECFD7F80215AA1C@na2-mail.mgc.mentorg.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 2581 Clarification Thread-Index: AcmzCIEdWOEaUcnQTbGGwjl94osyWQ== From: "Leino, Tammy" To: X-OriginalArrivalTime: 01 Apr 2009 20:28:30.0941 (UTC) FILETIME=[6BF9C0D0:01C9B308] X-Mailman-Approved-At: Thu, 02 Apr 2009 08:04:09 -0700 Subject: [tcpm] RFC 2581 Clarification 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, 01 Apr 2009 20:27:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B308.5E79C0AA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello All, =20 Can someone please clarify what is meant by "a segment" in step 4 of section 3.2 when discussing Fast Recovery: =20 4. Transmit a segment, if allowed by the new value of cwnd and the receiver's advertised window. =20 Specifically, could this "segment" be data on the retransmission queue that has not been ACKed (or retransmitted by Fast Retransmit) or is this "segment" only new data that has not yet been queued for retransmission? =20 I had always interpreted this as new data that has not been queued for retransmission, but in reading RFC 2018 regarding SACK, it seems that data on the retransmission queue is expected to be retransmitted in Fast Recovery as this section is outside the scope of the retransmission timer: =20 After the SACKed bit is turned on (as the result of processing a received SACK option), the data sender will skip that segment during any later retransmission.=20 =20 Your insight is greatly appreciated. =20 Best Regards, Tammy Leino =20 ------_=_NextPart_001_01C9B308.5E79C0AA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello All,

 

Can someone please clarify what is meant by “a = segment” in step 4 of section 3.2 when discussing Fast = Recovery:

 

   4.  Transmit a segment, if =
allowed by the new value of cwnd and =
the
       =
receiver's advertised window.

 

Specifically, could this “segment” be = data on the retransmission queue that has not been ACKed (or retransmitted by Fast Retransmit) or is this “segment” only new data that has not = yet been queued for retransmission?

 

I had always interpreted this as new data that has = not been queued for retransmission, but in reading RFC 2018 regarding SACK, it seems = that data on the retransmission queue is expected to be retransmitted in Fast = Recovery as this section is outside the scope of the retransmission = timer:

 
   After the SACKed bit is turned =
on (as the result of processing =
a
   received SACK option), the data =
sender will skip that segment =
during
   any later retransmission. =

 

Your insight is greatly = appreciated.

 

Best Regards,
Tammy Leino

 

------_=_NextPart_001_01C9B308.5E79C0AA-- From wwwrun@core3.amsl.com Thu Apr 2 08:07:06 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id EC83D28C222; Thu, 2 Apr 2009 08:07:06 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090402150706.EC83D28C222@core3.amsl.com> Date: Thu, 2 Apr 2009 08:07:06 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 15:07:07 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Improving TCP's Robustness to Blind In-Window Attacks ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-04-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11735&rfc_flag=0 The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/421/ From root@core3.amsl.com Thu Apr 2 10:15:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E1A763A6CA8; Thu, 2 Apr 2009 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090402171501.E1A763A6CA8@core3.amsl.com> Date: Thu, 2 Apr 2009 10:15:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-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: Thu, 02 Apr 2009 17:15: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 : Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets Author(s) : S. Floyd Filename : draft-ietf-tcpm-ecnsyn-08.txt Pages : 33 Date : 2009-04-02 The proposal in this document is experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of ECN in TCP SYN/ACK packets. This draft describes an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document describes the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN- marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN- Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmit timer). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-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-ecnsyn-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-02100212.I-D@ietf.org> --NextPart-- From nishida@sfc.wide.ad.jp Thu Apr 2 15:50:14 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2113A6D53 for ; Thu, 2 Apr 2009 15:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.585 X-Spam-Level: * X-Spam-Status: No, score=1.585 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] 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 Xl1k9vNI2sLW for ; Thu, 2 Apr 2009 15:50:13 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id AFA9F3A6824 for ; Thu, 2 Apr 2009 15:50:13 -0700 (PDT) Received: from localhost (cpu.sfc.wide.ad.jp [203.178.142.143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id B60C94C09C; Fri, 3 Apr 2009 07:51:10 +0900 (JST) Date: Fri, 03 Apr 2009 07:51:10 +0900 (JST) Message-Id: <20090403.075110.183124339.nishida@sfc.wide.ad.jp> To: tammy_leino@mentor.com From: Yoshifumi Nishida In-Reply-To: <2F83EB16CD718C43889CBCD31ECFD7F80215AA1C@na2-mail.mgc.mentorg.com> References: <2F83EB16CD718C43889CBCD31ECFD7F80215AA1C@na2-mail.mgc.mentorg.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] RFC 2581 Clarification 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, 02 Apr 2009 22:50:14 -0000 Hello Leino, I think you had better refer rfc3517 instead of rfc2581 for this. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: "Leino, Tammy" Subject: [tcpm] RFC 2581 Clarification Date: Wed, 1 Apr 2009 14:29:06 -0600 Message-ID: <2F83EB16CD718C43889CBCD31ECFD7F80215AA1C@na2-mail.mgc.mentorg.com> > Hello All, > > > > Can someone please clarify what is meant by "a segment" in step 4 of > section 3.2 when discussing Fast Recovery: > > > > 4. Transmit a segment, if allowed by the new value of cwnd and the > receiver's advertised window. > > > > Specifically, could this "segment" be data on the retransmission queue > that has not been ACKed (or retransmitted by Fast Retransmit) or is this > "segment" only new data that has not yet been queued for retransmission? > > > > I had always interpreted this as new data that has not been queued for > retransmission, but in reading RFC 2018 regarding SACK, it seems that > data on the retransmission queue is expected to be retransmitted in Fast > Recovery as this section is outside the scope of the retransmission > timer: > > > After the SACKed bit is turned on (as the result of processing a > received SACK option), the data sender will skip that segment during > any later retransmission. > > > > Your insight is greatly appreciated. > > > > Best Regards, > Tammy Leino > > > From wwwrun@core3.amsl.com Fri Apr 3 07:39:35 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 3A01F3A6CB6; Fri, 3 Apr 2009 07:39:34 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090403143935.3A01F3A6CB6@core3.amsl.com> Date: Fri, 3 Apr 2009 07:39:35 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-ecnsyn (Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 14:39:35 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-04-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14176&rfc_flag=0 The following IPR Declarations may be related to this I-D: From touch@ISI.EDU Tue Apr 7 16:02:47 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4198B3A6A72; Tue, 7 Apr 2009 16:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7JSOjjho9f4; Tue, 7 Apr 2009 16:02:46 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1F3E03A6A6D; Tue, 7 Apr 2009 16:02:46 -0700 (PDT) Received: from [75.215.125.96] (96.sub-75-215-125.myvzw.com [75.215.125.96]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n37MsheE003257; Tue, 7 Apr 2009 15:54:45 -0700 (PDT) Message-ID: <49DBD9AF.4040605@isi.edu> Date: Tue, 07 Apr 2009 15:54:39 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Magnus Westerlund References: <49CD09C2.40806@ericsson.com> In-Reply-To: <49CD09C2.40806@ericsson.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: softwires@ietf.org, tcpm@ietf.org Subject: Re: [tcpm] TCP MSS clamping to try to deal with MTU issues in Dual-Stack Lite 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, 07 Apr 2009 23:02:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, The solution has a bug: if TCP traffic uses TCP MD5 or TCP-AO, then it needs to be handled like non-TCP traffic, since MSS revision would destroy the packet's integrity. IMO, this should be handled the simple way - remove the TCP case, and handle all traffic the non-TCP way. Finally, if a NAT ever refuses to reassemble anything, it MUST issue an ICMP too-big IMO. The whole idea of creating a problem (encapsulating, decreasing the effective MSS on a path) then not cleaning it up yourself, or deciding when to clean it up based on *current* assumptions of network traffic is a bad idea and shouldn't be supported. Joe Magnus Westerlund wrote: > Hi, > > There is a proposal to use TCP MSS clamping to deal with MTU issues that > comes from Dual-stack lite's tunnel encapsulation. > > I think it would be good if TCPM could provide some feedback on this > proposal. > > The relevant document and section: > http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-00 > > 7.4. MTU > > > Using an encapsulation (IP in IP or L2TP) to carry IPv4 traffic over > IPv6 will reduce the effective MTU of the datagrams. Unfortunately, > path MTU discovery is not a reliable method to deal with this. As > such a combination of solutions is suggested: > > o For TCP traffic, let the carrier-grade NAT rewrite the MSS in the > first SYN packet to a lower value. > > o For non-TCP traffic, perform fragmentation and reassembly over the > tunnel between the home gateway and the carrier grade NAT. In > practice, this means put the IPv4 packet into a large IPv6 packet > and fragment/reassemble the IPv6 packet at each endpoint of the > tunnel. There is a performance price to pay for this. > Fragmentation is not very expensive, but reassembly can be, > especially on the carrier-grade NAT that would have to keep track > of a lot of flows. However, such a carrier-grade NAT would only > have to perform reassembly for large UDP packets sourced by > customers, not for large UDP packets received by customers. In > other words, streaming video to a customer would not have a > significant impact on the performance of the carrier-grade NAT, > but will require more work on the home gateway side. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknb2a8ACgkQE5f5cImnZrs0ewCg7ScElkpLrz20zSpTMnXuRApa CPsAoIyhk9N9K2fPpEJTyShMKeZNLxD/ =9ob2 -----END PGP SIGNATURE----- From rrs@lakerest.net Wed Apr 8 08:03:21 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5123F3A68C3 for ; Wed, 8 Apr 2009 08:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 x6wNsb8mIbJq for ; Wed, 8 Apr 2009 08:03:20 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id D74193A6A10 for ; Wed, 8 Apr 2009 08:03:19 -0700 (PDT) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n38F4LxE063760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 8 Apr 2009 11:04:21 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1239203061; h=Message-Id:From:To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:X-Mailer; b=DfV OPVyPeo9SwopfAAxVvB+CK1ilSUq1jC5MtKzZgSu8wsiJPGwpaejHVjYmvizrxqwLAN HYKYUdRbiL9SXEwQ== Message-Id: From: Randall Stewart To: tcpm@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 11:04:21 -0400 X-Mailer: Apple Mail (2.930.3) Subject: [tcpm] last call comment on draft-ietf-tcpm-tcpsecure-11.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, 08 Apr 2009 15:03:21 -0000 Hi all: I have one last call comment I would make to this document. My address is incorrect. Anantha, I think I sent you this earlier. Somehow it did not get in (nor my company affiliation).. if you don't have the correct information please ping me.. thanks R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From ananth@cisco.com Wed Apr 8 08:50:08 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7C83A6B27 for ; Wed, 8 Apr 2009 08:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6UQpg0YOly5 for ; Wed, 8 Apr 2009 08:50:07 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 643ED3A6A8E for ; Wed, 8 Apr 2009 08:50:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,345,1235952000"; d="scan'208";a="168746466" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 08 Apr 2009 15:51:14 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n38FpE9i009045; Wed, 8 Apr 2009 08:51:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n38FpE9H018917; Wed, 8 Apr 2009 15:51:14 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 08:51:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2009 08:51:14 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58070161A9@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] last call comment on draft-ietf-tcpm-tcpsecure-11.txt Thread-Index: Acm4W1R0RDLZ4pijQeKYAS1QgXN9RwABI1ig References: From: "Anantha Ramaiah (ananth)" To: "Randall Stewart" , X-OriginalArrivalTime: 08 Apr 2009 15:51:14.0787 (UTC) FILETIME=[D8F25B30:01C9B861] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=969; t=1239205874; x=1240069874; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20last=20call=20comment=20on=20d raft-ietf-tcpm-tcpsecure-11.txt |Sender:=20; bh=2fRPBko76UoF1TN/ER9hPYea7SfMoV0qfHHYRUIoZ9M=; b=t8hCgvQnYYCpb+OG/8m2RKZV/TpQB9+hq7lS0KoUwA4XSEN85h8luyd65q 8rm2smfJHLNbD7Qidu9ZK7bibA1XDwucwTDdlTIF/V6yfiiwljjqTagVBVlU XghQ76BNwS; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [tcpm] last call comment on draft-ietf-tcpm-tcpsecure-11.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, 08 Apr 2009 15:50:08 -0000 Randy, This is taken care of (already noted down). This will be addressed along with the boiler plate changes. -Anantha=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Randall Stewart > Sent: Wednesday, April 08, 2009 8:04 AM > To: tcpm@ietf.org > Subject: [tcpm] last call comment on draft-ietf-tcpm-tcpsecure-11.txt >=20 > Hi all: >=20 > I have one last call comment I would make to this document. >=20 > My address is incorrect. Anantha, I think I sent you this=20 > earlier. Somehow it did not get in (nor my company=20 > affiliation).. if you don't have the correct information=20 > please ping me.. >=20 > thanks >=20 > R > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > 803-345-0391(direct) >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From wesley.m.eddy@nasa.gov Mon Apr 13 07:18:36 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1283A6912 for ; Mon, 13 Apr 2009 07:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.112 X-Spam-Level: X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T-sVDZiCPFr for ; Mon, 13 Apr 2009 07:18:36 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id F36EF3A6822 for ; Mon, 13 Apr 2009 07:18:35 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id AAD80A819A; Mon, 13 Apr 2009 09:19:46 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162] (may be forged)) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n3DEJpvY018485; Mon, 13 Apr 2009 09:19:51 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Mon, 13 Apr 2009 09:19:46 -0500 From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" To: "tcpm@ietf.org" Date: Mon, 13 Apr 2009 09:19:43 -0500 Thread-Topic: draft-gont-tcp-security Thread-Index: Acm8QuP9tKYc17u8SZCdjlqxRHE6fw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-04-13_02:2009-04-13, 2009-04-13, 2009-04-13 signatures=0 Cc: Joe Abley , Joel Jaeggli , Fernando Gont Subject: [tcpm] draft-gont-tcp-security 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, 13 Apr 2009 14:18:36 -0000 Fernando has a draft intended for BCP, that has been discussed somewhat on the OPSEC and IETF mailing lists: http://tools.ietf.org/html/draft-gont-tcp-security-00 Since it concerns TCP and facets of both TCP implementation and stack configuration, TCPM holds the most technical ability to evaluate or work on this, in my opinion. As I understand, Fernando is interested in having this document done as a WG item, but hasn't gotten clear signals as to whether OPSEC or TCPM would be more appropriate, or on the relative level of support in the WGs to read/review/revise the material. It is a big document, but if TCPM'ers could take a look at it and let us know if they would support this in TCPM as a WG item, that would be very helpful. Or if you have other thoughts about how to handle it, of course share those too :). We don't really need a detailed review at this point ... just a discussion of whether there would be support for this work to happen in TCPM, if it's worthwhile, if it should be done somewhere else, etc. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From touch@ISI.EDU Mon Apr 13 09:40:03 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563793A6DCA for ; Mon, 13 Apr 2009 09:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nu+scl2bMI-R for ; Mon, 13 Apr 2009 09:40:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 635463A68B8 for ; Mon, 13 Apr 2009 09:40:02 -0700 (PDT) Received: from [75.215.162.89] (89.sub-75-215-162.myvzw.com [75.215.162.89]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3DGdMB6019358; Mon, 13 Apr 2009 09:39:27 -0700 (PDT) Message-ID: <49E36AB9.40507@isi.edu> Date: Mon, 13 Apr 2009 09:39:21 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" References: In-Reply-To: X-Enigmail-Version: 0.95.7 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: Joe Abley , Joel Jaeggli , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] draft-gont-tcp-security 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, 13 Apr 2009 16:40:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote: > Fernando has a draft intended for BCP, that has been discussed somewhat > on the OPSEC and IETF mailing lists: > > http://tools.ietf.org/html/draft-gont-tcp-security-00 > > Since it concerns TCP and facets of both TCP implementation and stack > configuration, TCPM holds the most technical ability to evaluate or > work on this, in my opinion. > > As I understand, Fernando is interested in having this document done > as a WG item, but hasn't gotten clear signals as to whether OPSEC or > TCPM would be more appropriate, or on the relative level of support in > the WGs to read/review/revise the material. > > It is a big document, but if TCPM'ers could take a look at it and let > us know if they would support this in TCPM as a WG item, that would be > very helpful. Or if you have other thoughts about how to handle it, > of course share those too :). I'm not at all clear that the WG needs this document. It summarizes issues already raised by the WG, and makes recommendations (IMO) in excess of what the WG has agreed upon for general use. TCP itself is not a secure protocol, nor is it intended to be. IMO, if there are operational issues with deploying TCP in environments under attack, that is an OPSEC issue. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknjarkACgkQE5f5cImnZrv2GQCfX+X26YXAqZD27LTAwciPSwVz a6cAn3XXvR96WFECBFr+bK5Gd3Fo75KL =6D2U -----END PGP SIGNATURE----- From fernando.gont.netbook.win@gmail.com Mon Apr 13 11:30:06 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265B33A6E34; Mon, 13 Apr 2009 11:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 muTeApU9Jvj6; Mon, 13 Apr 2009 11:30:05 -0700 (PDT) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id 0FCDA3A6E2F; Mon, 13 Apr 2009 11:30:04 -0700 (PDT) Received: by gxk7 with SMTP id 7so428171gxk.13 for ; Mon, 13 Apr 2009 11:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=3IzPFKzKkl4+PsCgLNf1d3Kql2unmMlSf7T0qzasK+I=; b=B30jQHGs9uoLN6y34ozvFJHwJNlvgsRP85uLBOhYn073NGTtTDRNS3bxr3HFnlf2tu Rz5MFmenP5Ffyl5+rPhRRdxQr+m0QNH1fz1to3fwnbhVjE+7XiyxNBIHim6slKL6Ycvz YtkTo8fjt2NLbQBAE31+kGDntkXMK5byDUnuM= 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=kSE0shl7OI39nZn7iBMCGYcF4Ix2SR0trz2MXIM2JlXdKTHlhTg8odsPmdg3xcPDH8 uq9Agt1NzntQVnyEwjFDu1XUcDun8kq6oS8LUQ4+A4FNw8orEGLq6pO96lqtbL7EaB4J I1k8ATCfPNfsNFpz/2ykjfHVxTwvUuQzdx0zc= Received: by 10.100.195.11 with SMTP id s11mr8176615anf.44.1239647475526; Mon, 13 Apr 2009 11:31:15 -0700 (PDT) Received: from ?192.168.0.151? (235-131-17-190.fibertel.com.ar [190.17.131.235]) by mx.google.com with ESMTPS id d12sm17875140and.24.2009.04.13.11.31.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 11:31:14 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E384E9.1050106@gont.com.ar> Date: Mon, 13 Apr 2009 15:31:05 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Joe Touch References: <49E36AB9.40507@isi.edu> In-Reply-To: <49E36AB9.40507@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Joel Jaeggli , "tcpm@ietf.org" , ietf@ietf.org, Joe Abley Subject: Re: [tcpm] draft-gont-tcp-security 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, 13 Apr 2009 18:30:06 -0000 Joe Touch wrote: > I'm not at all clear that the WG needs this document. Yes, we still have the option to ignore that vendors have had to figure out by themselves how to produce a resilient implementation of TCP, because the current IETF advice regarding this issues is close to null. So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a trivial attack in 2008 (Outpost24/CERT-FI), and we'll probably continue in this line, because we do nothing about it. > It summarizes issues already raised by the WG, I believe this statement is unfair with respect to our document. e.g., has the issues described in Section 4.3, Section 9.2, or Section 10 been brought to tcpm before??? > and makes recommendations (IMO) in > excess of what the WG has agreed upon for general use. > > TCP itself is not a secure protocol, nor is it intended to be. Yeah. But that does not mean that we should not do our best to improve it. Please talk to vendors. I don't want to reproduce here what seems to be the consensus among vendors with respect to the current state of affairs in terms of how up-to-date our specs are. Please let me know which implementations do not aim at doing this. If you know of any, please produce a fingerprint for nmap, and post an announcement to bugtraq/full-disclosure. The ecosystem will probably do the rest to get them updated. > IMO, if there are operational issues with deploying TCP in environments > under attack, that is an OPSEC issue. Yeah... problems with deploying it in the current Internet.... If tcpm agreed that opsec will be a better venue for this document, I'll be glad to pursue this effort there. At this point, tcpm and opsec are two possible options, with no preference for any of the two. 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 Mon Apr 13 11:43:55 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C71DA3A6D3C; Mon, 13 Apr 2009 11:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjkDcl86NDii; Mon, 13 Apr 2009 11:43:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C35E53A6DF4; Mon, 13 Apr 2009 11:43:54 -0700 (PDT) Received: from [75.215.162.89] (89.sub-75-215-162.myvzw.com [75.215.162.89]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3DIgLdb023271; Mon, 13 Apr 2009 11:42:23 -0700 (PDT) Message-ID: <49E3878C.9080200@isi.edu> Date: Mon, 13 Apr 2009 11:42:20 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fernando Gont References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar> In-Reply-To: <49E384E9.1050106@gont.com.ar> X-Enigmail-Version: 0.95.7 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: Joel Jaeggli , "tcpm@ietf.org" , ietf@ietf.org, Joe Abley Subject: Re: [tcpm] draft-gont-tcp-security 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, 13 Apr 2009 18:43:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >> I'm not at all clear that the WG needs this document. > > Yes, we still have the option to ignore that vendors have had to figure > out by themselves how to produce a resilient implementation of TCP, > because the current IETF advice regarding this issues is close to null. > > So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a > trivial attack in 2008 (Outpost24/CERT-FI), and we'll probably continue > in this line, because we do nothing about it. Whether we have this document or not, we will continue to have people who incorrectly assume that TCP is secure. >> It summarizes issues already raised by the WG, > > I believe this statement is unfair with respect to our document. e.g., > has the issues described in Section 4.3, Section 9.2, or Section 10 been > brought to tcpm before??? I didn't say that's all it does ;-) Agreed that it raises other issues, many of which are operational. >> and makes recommendations (IMO) in >> excess of what the WG has agreed upon for general use. >> >> TCP itself is not a secure protocol, nor is it intended to be. > > Yeah. But that does not mean that we should not do our best to improve > it. It means we should not try to give the incorrect impression that it *can* be secured. Interpreting every unexpected event as an attack makes a protocol robust but also brittle; TCP is intended to trade flexibility for security, AFAICT, because it is agnostic about intent, and gives the benefit of doubt at all times. This is a basic principle of design of our protocols - we are "liberal in what we receive" exactly because we do not interpret malicious intent where error could have occurred. Consider packet drops. That can happen due to loss, non-malicious corruption, or jamming, e.g. In the last case, it makes sense to blast copies of packets in the hopes of getting something through, but that's NOT what we assume. > Please talk to vendors. I don't want to reproduce here what seems to > be the consensus among vendors with respect to the current state of > affairs in terms of how up-to-date our specs are. Vendors misapply our protocols then complain that they don't work. Yes, there are operational issues, but one severe operational issue is not using security for some policy, financial, or operation expense and then complaining that nonsecure TCP is being attacked. ... >> IMO, if there are operational issues with deploying TCP in environments >> under attack, that is an OPSEC issue. > > Yeah... problems with deploying it in the current Internet... Not every TCP everywhere is under attack. If it were, you wouldn't be reading this message. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknjh4wACgkQE5f5cImnZruGTgCffkfEhZCD5dEXLn9TNTrRrrs0 CHUAoPyeyOYMKIQCHfPJkMk0sct+0LEZ =pxz5 -----END PGP SIGNATURE----- From fernando.gont.netbook.win@gmail.com Mon Apr 13 12:22:22 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69113A68F3; Mon, 13 Apr 2009 12:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 XB0c-BM3U9Xq; Mon, 13 Apr 2009 12:22:21 -0700 (PDT) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id DB96D3A68D1; Mon, 13 Apr 2009 12:22:16 -0700 (PDT) Received: by gxk7 with SMTP id 7so433315gxk.13 for ; Mon, 13 Apr 2009 12:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=yAi6IxUnt0bjyi7ie5/zh3Tc7neo7XV4qkrYVtULmzA=; b=KuBVCODLbazFQiaS6LFhulXACDzpRBEQVr8Hz+Y4XatjzclkoC42mfQC/0KCSTP2oy eOrARURh7F8e6456GiTrMzlPa0Ool8mpF89U5Dq0Vll2+CCLTbXuoQA93MR8zUozzHPl hT+PrT6x7pH8tejE93wxGfJErr3y4lRc4ZzwQ= 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=HG2g3eQGAEtAqMx2+WCZkLUxDJEQ5en5yXFxIhDaJVwJBwqY9+enDqclg/E9K6YXVJ 3ON9OrXM5X1DBPHjrmozLbSi7OSuKz/Op96FQMM5n6zqY+TeYZ1YmJDm5sqWAWye2Kq9 LSO2tCOUPJa/6oiDDX6UlWj2DcyulYOi6ycXs= Received: by 10.100.152.12 with SMTP id z12mr6046866and.96.1239650595208; Mon, 13 Apr 2009 12:23:15 -0700 (PDT) Received: from ?192.168.0.151? (235-131-17-190.fibertel.com.ar [190.17.131.235]) by mx.google.com with ESMTPS id b14sm139539ana.18.2009.04.13.12.23.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 12:23:14 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E39119.1060902@gont.com.ar> Date: Mon, 13 Apr 2009 16:23:05 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Joe Touch References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar> <49E3878C.9080200@isi.edu> In-Reply-To: <49E3878C.9080200@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Joel Jaeggli , "tcpm@ietf.org" , ietf@ietf.org, Joe Abley , opsec@ietf.org Subject: Re: [tcpm] draft-gont-tcp-security 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, 13 Apr 2009 19:22:22 -0000 Joe Touch wrote: >> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a >> trivial attack in 2008 (Outpost24/CERT-FI), and we'll probably continue >> in this line, because we do nothing about it. > > Whether we have this document or not, we will continue to have people > who incorrectly assume that TCP is secure. That's correct. But we also have people that do know it is not mean to be secure, but that it should be resilient enough so that it's still usable. One way or another, most stacks implement counter-measures for SYN-floods (on which tcpm did publish something), timers on the FIN-WAIT-2 state, port randomization (on which tsvwg is working), ICP ISN randomization, etc. The reason for which they did that was to improve TCP's security/resiliency. Would you argue in favour of predictable ISNs, predictable ports, time-less FIN-WAIT-2 state, etc.? -- I hope you wouldn't. >>> It summarizes issues already raised by the WG, >> I believe this statement is unfair with respect to our document. e.g., >> has the issues described in Section 4.3, Section 9.2, or Section 10 been >> brought to tcpm before??? > > I didn't say that's all it does ;-) Agreed that it raises other issues, > many of which are operational. Many of which arise if you expect to use TCP in some other scenario that just two computers in a LAN. If that makes those issues "operational", I agree. >>> TCP itself is not a secure protocol, nor is it intended to be. >> Yeah. But that does not mean that we should not do our best to improve >> it. > > It means we should not try to give the incorrect impression that it > *can* be secured. It's security/resiliency can be improved. After all, if that were not the case, I guess you're wasting your time with TCP-AO. Or is it that you believe the only way to improve a protocol is to throw crypto at it? > Interpreting every unexpected event as an attack makes > a protocol robust but also brittle; TCP is intended to trade flexibility > for security, AFAICT, because it is agnostic about intent, and gives the > benefit of doubt at all times. I would prefer that instead of making this type of broad statement, you would argue against a particular recommendation in draft-gont-tcp-security, and explain how it makes TCP more brittle. > Consider packet drops. That can happen due to loss, non-malicious > corruption, or jamming, e.g. In the last case, it makes sense to blast > copies of packets in the hopes of getting something through, but that's > NOT what we assume. Wasn't this very behavior what lead to the Internet congestion collapse in the 80's, or am I missing something? >> Please talk to vendors. I don't want to reproduce here what seems to >> be the consensus among vendors with respect to the current state of >> affairs in terms of how up-to-date our specs are. > > Vendors misapply our protocols then complain that they don't work. Yes, > there are operational issues, but one severe operational issue is not > using security for some policy, financial, or operation expense and then > complaining that nonsecure TCP is being attacked. Joe, we're talkng about a simple web server being taken down because of a SYN flood, a FIN-WAIT-2 flood, or the like. Even the most stupid web server should survive these types of attacks. Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Mon Apr 13 14:02:55 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750913A6EAE; Mon, 13 Apr 2009 14:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 tHvej6x4dtq0; Mon, 13 Apr 2009 14:02:54 -0700 (PDT) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id D242E3A6ED8; Mon, 13 Apr 2009 14:02:09 -0700 (PDT) Received: by gxk7 with SMTP id 7so441529gxk.13 for ; Mon, 13 Apr 2009 14:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=LSwc2s+dPhZk/nolwE375FttFgXivlgGBPLgK0LqKtA=; b=RHJTTn2m1JJIfBanAbyJ5zEKLdMb26fgUagylVGKBVIxJHCcSaiaGBppsihZlGBXaE ScuEO0wuPXOFPG1jyDVI35GyuBAZUW0zfbiTAtv8imErTG88hr4PCfoR78RpApIb4fmH 7o9OUX75MkELY7wnp4AEl7tHpIobqvnYk8Kws= 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=dTyms580WszwzjPtugbljTePnuhRL3+NFESvEzHjOSfQOtmlsXRuZLV6IMaZn0F99n mP51+VBWKydkX4kPyQYQwWE/c7jjtxQxMthCRXhKlyE/pfOUMuq5lrZnah9kDUSZYA36 DKJ4YnzpACzvuXL+YlzKDllHzLN502WXtXuXM= Received: by 10.100.7.13 with SMTP id 13mr8565634ang.10.1239656599991; Mon, 13 Apr 2009 14:03:19 -0700 (PDT) Received: from ?192.168.0.151? (235-131-17-190.fibertel.com.ar [190.17.131.235]) by mx.google.com with ESMTPS id c9sm853001ana.5.2009.04.13.14.03.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 14:03:19 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E3A88F.9060301@gont.com.ar> Date: Mon, 13 Apr 2009 18:03:11 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Smith, Donald" References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Touch' , 'Joe Abley' , "'opsec@ietf.org'" Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 13 Apr 2009 21:02:55 -0000 Smith, Donald wrote: >>>> Please talk to vendors. I don't want to reproduce here >> what seems to >>>> be the consensus among vendors with respect to the current >>>> state of affairs in terms of how up-to-date our specs are. > I talk to vendors a lot. I don't think there is a consensus on the > "how up-to-date our specs are". The consensus seems to be that the current state of affairs is something like: "a mess". Even if you do care to produce a resilient implementation, that task is going to be much harder than necessary. You don't know the amount of cycles we spent in producing draft-gont-tcp-security.... let alone the time it would take to move the advice in an actual implementation. > I can't even get a straight answer on how they addressed the > icmp-blind resets or the tcp-blind resets from several years ago. > There were several possible mitigations with some trade offs on each > of them. Yet finding out how your favorite vendor addressed those is > likely to be difficult. In many cases the lack of a straight answer may have to do with us being unable to get to consensus and get something published in a timely fashion. e.g., the last round on ICMP attacks against TCP was circa 2004. At that point an I-D was published on the subject (now draft-ietf-tcpm-icmp-attacks). Yet we're still nitpicking on it, when everybody did something about it five years ago. It becomes harder to get s staright answer when it's impossible for a vendor to point to a counter-measure that is supposed to be the result of a thorough review process, in a *timely* fashion. I'm aware there's an effort in the vendor community to improve the resiliency of TCP basedon the document published by UK CPNI. Yet we're still debating whether to ignore it or not.... maybe so that we can publish an RFC in the future tagging those implementations as non-compliant... or maybe to allow tcp vulnerabilities to be "rediscovered" every few years. 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 Mon Apr 13 14:02:59 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799AC28C13E; Mon, 13 Apr 2009 14:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 afWbtLTLw9qT; Mon, 13 Apr 2009 14:02:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 127CC3A67A4; Mon, 13 Apr 2009 14:02:40 -0700 (PDT) Received: from [75.215.162.89] (89.sub-75-215-162.myvzw.com [75.215.162.89]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3DL2Hgg027815; Mon, 13 Apr 2009 14:02:19 -0700 (PDT) Message-ID: <49E3A856.9020703@isi.edu> Date: Mon, 13 Apr 2009 14:02:14 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fernando Gont References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar> <49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> In-Reply-To: <49E39119.1060902@gont.com.ar> X-Enigmail-Version: 0.95.7 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: Joel Jaeggli , "tcpm@ietf.org" , ietf@ietf.org, Joe Abley , opsec@ietf.org Subject: Re: [tcpm] draft-gont-tcp-security 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, 13 Apr 2009 21:02:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a >>> trivial attack in 2008 (Outpost24/CERT-FI), and we'll probably continue >>> in this line, because we do nothing about it. >> Whether we have this document or not, we will continue to have people >> who incorrectly assume that TCP is secure. > > That's correct. But we also have people that do know it is not mean to > be secure, but that it should be resilient enough so that it's still > usable. One way or another, most stacks implement counter-measures for > SYN-floods (on which tcpm did publish something), timers on the > FIN-WAIT-2 state, port randomization (on which tsvwg is working), ICP > ISN randomization, etc. > > The reason for which they did that was to improve TCP's security/resiliency. > > Would you argue in favour of predictable ISNs, predictable ports, > time-less FIN-WAIT-2 state, etc.? -- I hope you wouldn't. These measures can be used to reduce the impact of attacks when TCP is not secured. However, they DO NOT make TCP secure. They DO make TCP more brittle - they limit the way in which two legitimate endpoints can do legitimate things. >>>> It summarizes issues already raised by the WG, >>> I believe this statement is unfair with respect to our document. e.g., >>> has the issues described in Section 4.3, Section 9.2, or Section 10 been >>> brought to tcpm before??? >> I didn't say that's all it does ;-) Agreed that it raises other issues, >> many of which are operational. > > Many of which arise if you expect to use TCP in some other scenario that > just two computers in a LAN. If that makes those issues "operational", I > agree. Many of those don't arise for computers in a wide area, or with millions of other computers on the network either. They arise only when there are active attacks, and only for some kinds of attackers (on-path, off-path, high-speed access, etc.) IMO, any decision which would be enabled or disabled depending on whether security was a concern or performance was needed is operational. E.g., port randomization helps only when attackers are off-path and when port use is a fraction of the active port space. That's operational. Ditto for ISN randomization. I.e., if the protection is not needed in the absence of attacks, it may be operational. >>>> TCP itself is not a secure protocol, nor is it intended to be. >>> Yeah. But that does not mean that we should not do our best to improve >>> it. >> It means we should not try to give the incorrect impression that it >> *can* be secured. > > It's security/resiliency can be improved. After all, if that were not > the case, I guess you're wasting your time with TCP-AO. Or is it that > you believe the only way to improve a protocol is to throw crypto at it? I *know* that the only way to secure a protocol is to throw crypto at it. I also *know* that unexpected packets are *not* indications of attacks. These two things are not evident in this document, and should be. Further, this document should make a case as to whether the improvements are operational or not. AFAICT, most are operational. >> Interpreting every unexpected event as an attack makes >> a protocol robust but also brittle; TCP is intended to trade flexibility >> for security, AFAICT, because it is agnostic about intent, and gives the >> benefit of doubt at all times. > > I would prefer that instead of making this type of broad statement, you > would argue against a particular recommendation in > draft-gont-tcp-security, and explain how it makes TCP more brittle. Randomizing ports and ISNs assumes there is a window over which some values are NOT used; that window precludes legitimate exchanges from occurring. That is what I mean by "brittle." >> Consider packet drops. That can happen due to loss, non-malicious >> corruption, or jamming, e.g. In the last case, it makes sense to blast >> copies of packets in the hopes of getting something through, but that's >> NOT what we assume. > > Wasn't this very behavior what lead to the Internet congestion collapse > in the 80's, or am I missing something? Loss of a segment can mean: a) congestion (correlated drops) b) non-correlated drops (not related to increasing traffic) c) active removal (attack) If (a), then you backoff. That's how congestion collapse was addressed. If you believe that packet drops are caused by either non-correlated drops or active removal, you send MORE - you send copies of each packet, e.g. That is NOT what we assume, but what I presume you ought to recommend in a document that assumes that every event that COULD have been an attack probably is an attack. >>> Please talk to vendors. I don't want to reproduce here what seems to >>> be the consensus among vendors with respect to the current state of >>> affairs in terms of how up-to-date our specs are. >> Vendors misapply our protocols then complain that they don't work. Yes, >> there are operational issues, but one severe operational issue is not >> using security for some policy, financial, or operation expense and then >> complaining that nonsecure TCP is being attacked. > > Joe, we're talkng about a simple web server being taken down because of > a SYN flood, a FIN-WAIT-2 flood, or the like. Even the most stupid web > server should survive these types of attacks. If you're talking about implementation advice (don't put all your resources in pending connections), I agree that a good implementation should be implemented well. But that's operational / implementation advice, not protocol advice. I do not agree that all web servers should implement SYN cookies, e.g. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknjqFYACgkQE5f5cImnZrtBNwCgiJPsTDBt34Im+s/TFkBm90DE Xn4AoNlUvCAucvZoVVMTpex4sMXAaXb2 =1ijT -----END PGP SIGNATURE----- From touch@ISI.EDU Mon Apr 13 14:08:13 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CDA53A6A06; Mon, 13 Apr 2009 14:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np9EJSfzLIk1; Mon, 13 Apr 2009 14:08:12 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id AB7B23A6924; Mon, 13 Apr 2009 14:08:12 -0700 (PDT) Received: from [75.215.162.89] (89.sub-75-215-162.myvzw.com [75.215.162.89]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3DL8dSh029094; Mon, 13 Apr 2009 14:08:41 -0700 (PDT) Message-ID: <49E3A9D6.4030504@isi.edu> Date: Mon, 13 Apr 2009 14:08:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Smith, Donald" References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Fernando Gont' Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 13 Apr 2009 21:08:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Donald, I'm confused by your post. You appear to believe that TCP is intended to be secure. Note that TCP does not require either the MD5 or AO extension. Smith, Donald wrote: > > (coffee != sleep) & (!coffee == sleep) > Donald.Smith@qwest.com gcia > >> -----Original Message----- >> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >> On Behalf Of Fernando Gont >> Sent: Monday, April 13, 2009 1:23 PM >> To: Joe Touch >> Cc: tcpm@ietf.org; ietf@ietf.org; Joe Abley; opsec@ietf.org; >> Lars Eggert; Eddy,Wesley M. (GRC-RCN0)[Verizon] >> Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security >> >> Joe Touch wrote: >> >>>> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a >>>> trivial attack in 2008 (Outpost24/CERT-FI), and we'll >> probably continue >>>> in this line, because we do nothing about it. >>> Whether we have this document or not, we will continue to >> have people >>> who incorrectly assume that TCP is secure. > > Secure is a general term. TCP was intended to address several areas of security. > The classic tenets for computer security is: > CIA -> Confidentiality, Integrity and Availability. > TCP doesn't attempt to address Confidentiality. > However it was designed to address integrity and availability so > failures in those areas should be documented and addressed in some > fashion. Can you explain this? Where is the integrity protection? Where is the availability specified? ... >> It's security/resiliency can be improved. After all, if that were not >> the case, I guess you're wasting your time with TCP-AO. Or is it that >> you believe the only way to improve a protocol is to throw >> crypto at it? > > Adding crypto improves confidentiality and integrity but is counter > productive to availability as most > crypto engines are prone to fairly low pps resource exhaustion > attacks. All prevention methods are susceptible to computational resource attacks, since all increase the operations performed on a packet. It is commonly assumed that this is a desirable tradeoff, and that the computational resources can be totally protected with line-rate dedicated computation (e.g., hardware assist). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknjqdYACgkQE5f5cImnZruhawCgqqkl3NPljMkNRz8buEYROGUO R2kAnRHhQmWJVtXq/j2wbNy64q6QWe+u =OkiS -----END PGP SIGNATURE----- From touch@ISI.EDU Mon Apr 13 14:16:51 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F033D3A6ECA; Mon, 13 Apr 2009 14:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbJQWIjqok+C; Mon, 13 Apr 2009 14:16:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DDB2B3A6EC8; Mon, 13 Apr 2009 14:16:49 -0700 (PDT) Received: from [75.215.162.89] (89.sub-75-215-162.myvzw.com [75.215.162.89]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3DLGn33001231; Mon, 13 Apr 2009 14:16:51 -0700 (PDT) Message-ID: <49E3ABC0.1050601@isi.edu> Date: Mon, 13 Apr 2009 14:16:48 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fernando Gont References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> In-Reply-To: <49E3A88F.9060301@gont.com.ar> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , "Smith, Donald" , 'Joe Abley' , "'opsec@ietf.org'" Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 13 Apr 2009 21:16:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Smith, Donald wrote: > >>>>> Please talk to vendors. I don't want to reproduce here >>> what seems to >>>>> be the consensus among vendors with respect to the current >>>>> state of affairs in terms of how up-to-date our specs are. >> I talk to vendors a lot. I don't think there is a consensus on the >> "how up-to-date our specs are". > > The consensus seems to be that the current state of affairs is something > like: "a mess". Even if you do care to produce a resilient > implementation, that task is going to be much harder than necessary. You > don't know the amount of cycles we spent in producing > draft-gont-tcp-security.... let alone the time it would take to move the > advice in an actual implementation. Advice in making a hardened version of TCP would be useful to the implementation community. However, if you're saying that TCP specs in general are a mess, yes they are. That's why we created a roadmap document, and why it needs to be maintained. If you're suggesting we need a clean single documentation of what TCP is, I might even agree. However: 1) TCPM is not the place that would generate it (IMO, that'd be TSVWG) 2) this document is not a step in that direction You've produced a summary of issues you feel would harden TCP. I feel that some of them make TCP more brittle, and some make TCP unnecessarily complex, and in both cases the mods are not needed in the general Internet. TCPsecure is a good example; it has caveats in its ID that indicate where it is useful and where it is not -- it is NOT a general solution for the entire Internet (the WG basically agreed to that with the wording for its use cases). >> I can't even get a straight answer on how they addressed the >> icmp-blind resets or the tcp-blind resets from several years ago. >> There were several possible mitigations with some trade offs on each >> of them. Yet finding out how your favorite vendor addressed those is >> likely to be difficult. > > In many cases the lack of a straight answer may have to do with us being > unable to get to consensus and get something published in a timely > fashion. e.g., the last round on ICMP attacks against TCP was circa > 2004. At that point an I-D was published on the subject (now > draft-ietf-tcpm-icmp-attacks). Yet we're still nitpicking on it, when > everybody did something about it five years ago. Uh, well, we're deciding whether we agree with what's been deployed. Deploying some of these changes hasn't always been a good idea; if it were, we'd be agreeing to it. > It becomes harder to get s staright answer when it's impossible for a > vendor to point to a counter-measure that is supposed to be the result > of a thorough review process, in a *timely* fashion. Can you be as specific here as you want us to be? What exactly does a vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing known countermeasures? > I'm aware there's an effort in the vendor community to improve the > resiliency of TCP basedon the document published by UK CPNI. Yet we're > still debating whether to ignore it or not.... maybe so that we can > publish an RFC in the future tagging those implementations as > non-compliant... or maybe to allow tcp vulnerabilities to be > "rediscovered" every few years. If the vendors are following this doc already, then we REALLY need to ensure it's updated with advice appropriate to the context in which it is deployed. Running around saying the sky is falling for everyone isn't going to help. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknjq78ACgkQE5f5cImnZrv1lwCg3sR/xHE5SRW9nld39xFN+ZCb rWkAn2pA80tWrpS/8iQTau97RoFpaEBl =yF7F -----END PGP SIGNATURE----- From fernando.gont.netbook.win@gmail.com Mon Apr 13 14:23:52 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80673A6A5E; Mon, 13 Apr 2009 14:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5su+B7esvXYk; Mon, 13 Apr 2009 14:23:51 -0700 (PDT) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id 9B8573A67A4; Mon, 13 Apr 2009 14:23:48 -0700 (PDT) Received: by gxk7 with SMTP id 7so443249gxk.13 for ; Mon, 13 Apr 2009 14:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=64Gl+5plokEKTs1Br770HidGNf+oN2DquiyA2hoPf0Y=; b=n8+VOeiomeTJIqrOcTnbPTx6HAAN4H1rgAY1cFWaySFOL1PFM4poQhm6ofRglpVCgy R6L6ck4DarwVxVLPzVELDjw8v3TFA6jp1/pkyVO19ERVgX4j6tF8GIkzVb80nSIAUb0s MQSpe21kvTegq4sx5PGX0lXyCccUnk2tBBqQE= 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=ddT1AIabC2yZYxpBGeqVUfja1MQvUMth+TPSfYPWSnDZ6BbmQ3czgDfGHk5ggBmbdz mQ4WDV8Pvg7R9yt/K/2YJGGm1YM+oR4abjCbS3VAM2XYPMF79hYJCtyJy3/akeYVReOr jOXk/PzGwfNzaewWgudG9eTno8v1sN1yTmoHo= Received: by 10.100.177.10 with SMTP id z10mr243356ane.2.1239657898990; Mon, 13 Apr 2009 14:24:58 -0700 (PDT) Received: from ?192.168.0.151? (235-131-17-190.fibertel.com.ar [190.17.131.235]) by mx.google.com with ESMTPS id d29sm844100and.14.2009.04.13.14.24.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 14:24:58 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E3ADA4.1090402@gont.com.ar> Date: Mon, 13 Apr 2009 18:24:52 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ietf@ietf.org References: <20090402150706.EC83D28C222@core3.amsl.com> In-Reply-To: <20090402150706.EC83D28C222@core3.amsl.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard 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, 13 Apr 2009 21:23:52 -0000 Folks, Some last call comments: * The document never mentions the fact that this document is IPR-encumbered. As far as I recall, much of the dicussion within tcpm with respect to the level of requirements of this document (MAY/SHOULD/MUST, etc.) had to do with this fact. I believe the document should include a warning mentioning that there's an IPR on the document, so that implementers can consider this point in their decision of whether to implement the described mechanisms or not. * The document discusses blind attacks, and to some extent assesses the difficulty in guessing the four-tuple that identifies a TCP connection. However, it does not even mention port randomization, which is probably the most simple and straightforward approach for mitigating blind attacks against TCP. This was raised by me and other quite a few times in the tcpm wg list, pre and post wglc, but this comment was never addressed. It's particularly curious that port randomization is not mentioned when tsvwg is working on it (draft-ietf-tsvwg-port-randomization). * Among the factors that determine how easy these attacks be exploited is the window size. This document should provide, at the very least, pointers with advice on what to do with the tcp window. While quickly skimming through RFC 4953, it seems it has some advice on the TCP window. We do offer a lengthy discussion of this and other issues in draft-gont-tcp-security and http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf * Yet another factor is TCP ISN randomization. At the very least, this document could/should a pointer to RFC 1948. We do offer a lengthy discussion of this and other issues in draft-gont-tcp-security and http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf * Just of the top of my head: Hadn't the BGP spec been updated so that a well-known port was not required as the *source* port? * The counter-measure of for the SYN-based reset attack may have missed a common heuristics for the handling of SYN segments. See pages 86 and 87 of the UK CPNI paper on TCP security. FWIW, we argue that the processing of SYN segments proposed in [Ramaiah et al, 2008] should apply only for connections in any of the synchronized states other than the TIME-WAIT state. * When it comes to TCP-based blind-connection reset attacks, there's a much more trivial -- yet not discussed before? -- alternative. See Section 11.1.3 and Section 11.1.4 in draft-gont-tcp-security and the CPNI paper (http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf). These variants should, at the very least, be mentioned and a pointer provided to them as, at least in theory, are much easier to exploit. * When it comes to the data injection attack, Michael Zalewski sketched another attack vector which may be easier to exploit. We discuss it in Section 16.2 of draft-gont-tcp-security and the CPNI doc, along with advice. IMO, this vector should be mentioned, too. Needless to say, I'm in favor of improving the robustness of TCP and, IPRs-aside, I'm happy with the implementation of the counter-measures described in the tcpsecure I-D (all three). I'm also glad that this doc is getting close to publication. Five years working on a document is quite a lot of time! (yes, it could have been worse, some might argue). Thanks! Kind regards, Fernando Gont The IESG wrote: > The IESG has received a request from the TCP Maintenance and Minor > Extensions WG (tcpm) to consider the following document: > > - 'Improving TCP's Robustness to Blind In-Window Attacks ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2009-04-16. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-11.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11735&rfc_flag=0 > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/421/ > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > -- 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 Mon Apr 13 15:15:31 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94743A67B1; Mon, 13 Apr 2009 15:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 O-FOR4sVQWYl; Mon, 13 Apr 2009 15:15:30 -0700 (PDT) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id 4CF063A6C22; Mon, 13 Apr 2009 15:15:30 -0700 (PDT) Received: by gxk7 with SMTP id 7so448239gxk.13 for ; Mon, 13 Apr 2009 15:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=6HLm2gJLCSrNWV43539qUV1LrzTRHqLp1J+4IafeMII=; b=gBjuQtq+EvGyEF1UGOsYGd9a9sE1t79yGECoWld7ACruG7XYjqUxNjZNsXCgx/La6V 7CcRq/9dYAYT6viv5oWmWqpKdTqla15Gn2/1Lek4QwX8wCptrryRLHBMCZN4EQ7pXGhJ qIK67qV1WaihVEUMP+yuYGdkweORg6J8QGA2w= 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=UYFkvxkRhrFAu24OuhTopLMiCJSxnih+3tAOoOt9CEvVcg9yq4GDIJ3sMQukWtLYgA Oz8wrUlAuZx9DeDa7LIoudXSaq/pJTHvuT4ogKYfcdy712PvJfXiDga3AXDS9TeaIjji D7R0Ewho9yVgjMiuhHfh/sp2HmzZyR4K7biWg= Received: by 10.100.152.12 with SMTP id z12mr5125294and.141.1239660998200; Mon, 13 Apr 2009 15:16:38 -0700 (PDT) Received: from ?192.168.0.151? (235-131-17-190.fibertel.com.ar [190.17.131.235]) by mx.google.com with ESMTPS id d24sm249633and.37.2009.04.13.15.16.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 15:16:37 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E3B9BF.1060901@gont.com.ar> Date: Mon, 13 Apr 2009 19:16:31 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Joe Touch References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> In-Reply-To: <49E3ABC0.1050601@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , "Smith, Donald" , 'Joe Abley' , "'opsec@ietf.org'" Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 13 Apr 2009 22:15:31 -0000 Joe Touch wrote: >> The consensus seems to be that the current state of affairs is something >> like: "a mess". Even if you do care to produce a resilient >> implementation, that task is going to be much harder than necessary. You >> don't know the amount of cycles we spent in producing >> draft-gont-tcp-security.... let alone the time it would take to move the >> advice in an actual implementation. > > Advice in making a hardened version of TCP would be useful to the > implementation community. To a large extent this is what draft-gont-tcp-security is about. > However, if you're saying that TCP specs in general are a mess, yes they > are. That's why we created a roadmap document, and why it needs to be > maintained. If you're suggesting we need a clean single documentation of > what TCP is, I might even agree. However: > > 1) TCPM is not the place that would generate it > (IMO, that'd be TSVWG) > > 2) this document is not a step in that direction The tcp roadmap is a roadmap to the documents that the IETF has published. There's lots of stuff that has not been published by the IETF and that therefore is not discussed in the tcp roadmap. This is another area in which this document tries to help. > You've produced a summary of issues you feel would harden TCP. I feel > that some of them make TCP more brittle, and some make TCP unnecessarily > complex, and in both cases the mods are not needed in the general > Internet. Is there nothing in the document with which you agree? > TCPsecure is a good example; it has caveats in its ID that > indicate where it is useful and where it is not -- it is NOT a general > solution for the entire Internet (the WG basically agreed to that with > the wording for its use cases). c'mon Joe.. IMO, tcpsecure needed to include those statements about usefulness in large part because it was IPR-encumbered, and in part as a political workaround that would avoid further waste of time in endless discussions. >> In many cases the lack of a straight answer may have to do with us being >> unable to get to consensus and get something published in a timely >> fashion. e.g., the last round on ICMP attacks against TCP was circa >> 2004. At that point an I-D was published on the subject (now >> draft-ietf-tcpm-icmp-attacks). Yet we're still nitpicking on it, when >> everybody did something about it five years ago. > > Uh, well, we're deciding whether we agree with what's been deployed. > Deploying some of these changes hasn't always been a good idea; if it > were, we'd be agreeing to it. Some people prefer to get work done instead of committing/wasting lots of cycles in endless discussions. >> It becomes harder to get s staright answer when it's impossible for a >> vendor to point to a counter-measure that is supposed to be the result >> of a thorough review process, in a *timely* fashion. > > Can you be as specific here as you want us to be? What exactly does a > vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing > known countermeasures? What's "the existing known counter-measures"? >> I'm aware there's an effort in the vendor community to improve the >> resiliency of TCP basedon the document published by UK CPNI. Yet we're >> still debating whether to ignore it or not.... maybe so that we can >> publish an RFC in the future tagging those implementations as >> non-compliant... or maybe to allow tcp vulnerabilities to be >> "rediscovered" every few years. > > If the vendors are following this doc already, then we REALLY need to > ensure it's updated with advice appropriate to the context in which it > is deployed. FWIW, vendors are following the UK CPNI document. The idea of bringing those results to the IETF is so that these results/advice can be further discussed, more eyes look into them, and the doc is modified if it is felt necessary. > Running around saying the sky is falling for everyone isn't > going to help. Who did that? We worked on this document very silently for a couple of years. If we had wanted that "sky is falling" approach, we would have gone to the press before showing anything (like quite a few folks have been doing in the recent past). Or we could have announced part of this stuff as "vulnerabilities" to the press.. That wasn't the case. I tried to get many people to review the document, and have the document be as objective as possible. At least for the ip-security counterpart, I recall asking you to have a look at it before publication, even when I knew that you'd most likely disagree with large parts of the document. This project is already done.... but nevertheless I'm still spending some cycles to bring this to the IETF, because I truly believe the IETF should work on it. Neither me nor UK CPNI have IPRs or anything on the material covered in our document... so there's no hidden motivation in all this. Honestly, I'm not sure why you always have to knock down others' efforts on a "by default" basis, and prejudge the motivation behind those efforts. 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 Mon Apr 13 15:22:28 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613313A6858; Mon, 13 Apr 2009 15:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qivFj0jN3KuL; Mon, 13 Apr 2009 15:22:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7DD673A68A8; Mon, 13 Apr 2009 15:22:27 -0700 (PDT) Received: from [75.215.162.89] (89.sub-75-215-162.myvzw.com [75.215.162.89]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3DMN0R2016634; Mon, 13 Apr 2009 15:23:02 -0700 (PDT) Message-ID: <49E3BB44.9000206@isi.edu> Date: Mon, 13 Apr 2009 15:23:00 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Smith, Donald" References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A9D6.4030504@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Fernando Gont' Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 13 Apr 2009 22:22:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Smith, Donald wrote: ... >>>> The classic tenets for computer security is: >>>> CIA -> Confidentiality, Integrity and Availability. >>>> TCP doesn't attempt to address Confidentiality. >>>> However it was designed to address integrity and availability so >>>> failures in those areas should be documented and addressed in some >>>> fashion. > Can you explain this? Where is the integrity protection? Where is the > availability specified? > >> Checksumming in tcp/ip is intended to provide intregrity protection. Error protection != integrity protection. Anyone can reconstitute the checksum, so it is not an integrity mechanism. >> Mind you it is NOT tamper proof but that is the intent. What is your definition of integrity? Mine means some assurance that what was sent is what is received. Anything that any intermediary can reconstitute trivially is not protected. >> Detection of lost packets, retransmitions, reassembly of fragments, >> congestion notification, dynamic routing and many other tcp/ip features >> are intended to address availablity. The first group (loss detection, retransmission, reassy) address links with errors, not 'availability' in the usual sense. The second set might apply, but aren't part of TCP per se (TCP uses the absence of info to indicate congestion, not the presence, at least in the required base of the protocol). > ... >>>>> It's security/resiliency can be improved. After all, if > that were not >>>>> the case, I guess you're wasting your time with TCP-AO. Or > is it that >>>>> you believe the only way to improve a protocol is to throw >>>>> crypto at it? >>>> Adding crypto improves confidentiality and integrity but is counter >>>> productive to availability as most >>>> crypto engines are prone to fairly low pps resource exhaustion >>>> attacks. > All prevention methods are susceptible to computational resource > attacks, since all increase the operations performed on a > packet. >> GTSM is a valuable exception to this statement but other then that I tend to agree:) > > It is > commonly assumed that this is a desirable tradeoff, and that the > computational resources can be totally protected with line-rate > dedicated computation (e.g., hardware assist). >> I believe that is a common assumption however I don't believe that assumption is correct. >> I do a fair amount of router testing and although some portions of >> ipv4 are hardware assisted and therefore line-rate there are still many >> paths to the "slow path". IPv6 has many more routes to the slow path:( First, I'm speaking of hardware crypto assist. I'm assuming fast-path packets. Slow-path packets are self-correcting in many routers - they're dumped when their queue overflows, or are simply processed *very* slowly. If you care about computational resources, you put in line-rate hardware, period. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknju0MACgkQE5f5cImnZruVggCguJGkydTXB9yWgK+nPfpBqQy8 izAAoIT+9Tmof98TX+0WLdYkCFcj4Ikx =ac+U -----END PGP SIGNATURE----- From touch@ISI.EDU Mon Apr 13 15:38:07 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7CF3A6EDA; Mon, 13 Apr 2009 15:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 AAY2MmlPsbYu; Mon, 13 Apr 2009 15:38:05 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B67783A6858; Mon, 13 Apr 2009 15:38:03 -0700 (PDT) Received: from [75.215.162.89] (89.sub-75-215-162.myvzw.com [75.215.162.89]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3DMcHKi019716; Mon, 13 Apr 2009 15:38:19 -0700 (PDT) Message-ID: <49E3BED9.1030701@isi.edu> Date: Mon, 13 Apr 2009 15:38:17 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fernando Gont References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> In-Reply-To: <49E3B9BF.1060901@gont.com.ar> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , "Smith, Donald" , 'Joe Abley' , "'opsec@ietf.org'" Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 13 Apr 2009 22:38:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>> The consensus seems to be that the current state of affairs is something >>> like: "a mess". Even if you do care to produce a resilient >>> implementation, that task is going to be much harder than necessary. You >>> don't know the amount of cycles we spent in producing >>> draft-gont-tcp-security.... let alone the time it would take to move the >>> advice in an actual implementation. >> Advice in making a hardened version of TCP would be useful to the >> implementation community. > > To a large extent this is what draft-gont-tcp-security is about. Implementation advice is outside the scope of the IETF. It's not even operational, IMO. >> However, if you're saying that TCP specs in general are a mess, yes they >> are. That's why we created a roadmap document, and why it needs to be >> maintained. If you're suggesting we need a clean single documentation of >> what TCP is, I might even agree. However: >> >> 1) TCPM is not the place that would generate it >> (IMO, that'd be TSVWG) >> >> 2) this document is not a step in that direction > > The tcp roadmap is a roadmap to the documents that the IETF has > published. There's lots of stuff that has not been published by the IETF > and that therefore is not discussed in the tcp roadmap. > > This is another area in which this document tries to help. Those are documents that the IETF may or may not agree with. Neither "Implemented" nor "published" doesn't mean we should endorse that solution. >> You've produced a summary of issues you feel would harden TCP. I feel >> that some of them make TCP more brittle, and some make TCP unnecessarily >> complex, and in both cases the mods are not needed in the general >> Internet. > > Is there nothing in the document with which you agree? That'd be harsh. I agree with some of the implementation advice as implementation advice. I agree that, in risk-prone environments (where packets can be tapped, e.g.), some of the recommendations are appropriate. I'm disagreeing primarily with the general tone and balance of the document. >> TCPsecure is a good example; it has caveats in its ID that >> indicate where it is useful and where it is not -- it is NOT a general >> solution for the entire Internet (the WG basically agreed to that with >> the wording for its use cases). > > c'mon Joe.. IMO, tcpsecure needed to include those statements about > usefulness in large part because it was IPR-encumbered, and in part as a > political workaround that would avoid further waste of time in endless > discussions. I disagree. Even if it weren't IPR encumbered, I would disagree with widescale deployment of a modification to TCP that answers a RST with one *or more* ACKs. As I said numerous times w.r.t. that document, the modifications it suggests are generally not needed, unnecessarily complicate packet processing, and since they don't protect from in-window injection attacks, I find them useless in the general case. >>> In many cases the lack of a straight answer may have to do with us being >>> unable to get to consensus and get something published in a timely >>> fashion. e.g., the last round on ICMP attacks against TCP was circa >>> 2004. At that point an I-D was published on the subject (now >>> draft-ietf-tcpm-icmp-attacks). Yet we're still nitpicking on it, when >>> everybody did something about it five years ago. >> Uh, well, we're deciding whether we agree with what's been deployed. >> Deploying some of these changes hasn't always been a good idea; if it >> were, we'd be agreeing to it. > > Some people prefer to get work done instead of committing/wasting lots > of cycles in endless discussions. Publishing recommendations without validating them isn't wasting time. >>> It becomes harder to get s staright answer when it's impossible for a >>> vendor to point to a counter-measure that is supposed to be the result >>> of a thorough review process, in a *timely* fashion. >> Can you be as specific here as you want us to be? What exactly does a >> vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing >> known countermeasures? > > What's "the existing known counter-measures"? Limit cycles/resources available for new connections, e.g., for SYN attacks -- as is already done for things like IKE. >>> I'm aware there's an effort in the vendor community to improve the >>> resiliency of TCP basedon the document published by UK CPNI. Yet we're >>> still debating whether to ignore it or not.... maybe so that we can >>> publish an RFC in the future tagging those implementations as >>> non-compliant... or maybe to allow tcp vulnerabilities to be >>> "rediscovered" every few years. >> If the vendors are following this doc already, then we REALLY need to >> ensure it's updated with advice appropriate to the context in which it >> is deployed. > > FWIW, vendors are following the UK CPNI document. The idea of bringing > those results to the IETF is so that these results/advice can be further > discussed, more eyes look into them, and the doc is modified if it is > felt necessary. I've been saying I feel that mods are necessary, and you keep complaining. If you're here for a rubber stamp, you came to the wrong WG ;-) >> Running around saying the sky is falling for everyone isn't >> going to help. > > Who did that? We worked on this document very silently for a couple of > years. If we had wanted that "sky is falling" approach, we would have > gone to the press before showing anything (like quite a few folks have > been doing in the recent past). Or we could have announced part of this > stuff as "vulnerabilities" to the press.. The sky has been falling in this WG for several years. Although this document is the first aggregation of such recommendations, as you know it's composed of many documents you yourself have been discussing for that period in this WG.. > That wasn't the case. > > I tried to get many people to review the document, and have the document > be as objective as possible. At least for the ip-security counterpart, I > recall asking you to have a look at it before publication, even when I > knew that you'd most likely disagree with large parts of the document. > > This project is already done.... but nevertheless I'm still spending > some cycles to bring this to the IETF, because I truly believe the IETF > should work on it. Neither me nor UK CPNI have IPRs or anything on the > material covered in our document... so there's no hidden motivation in > all this. > > Honestly, I'm not sure why you always have to knock down others' efforts > on a "by default" basis, and prejudge the motivation behind those efforts. I'm asking the question I apparently keep needing to ask: Why do you think that just because something is implemented we should recommend it? Why do you think that a message that isn't expected indicates an attack to be defended against, vs. the actions of a benign endpoint? For this document, yes, this means: Does the IETF need such a document at all? If we do need such a document, is this the right content? I have a high bar for the need for modifications to TCP, and the need to propagate local solutions to every endpoint in the Internet. That is the approach I expect of others in this WG, and yes, I'll speak out when it's not the case. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknjvtgACgkQE5f5cImnZru0lwCg6zvNwRNl9SBH1QcMo4Y7xnMz vRwAoOVpLWkco+DKxLFhY26CVR2LtaJ5 =YkNg -----END PGP SIGNATURE----- From ananth@cisco.com Mon Apr 13 16:22:46 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B29828C146; Mon, 13 Apr 2009 16:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NI5+AJUlVAgp; Mon, 13 Apr 2009 16:22:45 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F38053A6765; Mon, 13 Apr 2009 16:22:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,182,1238976000"; d="scan'208";a="71832337" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 13 Apr 2009 23:23:56 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3DNNuoI011078; Mon, 13 Apr 2009 16:23:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n3DNNuhr025577; Mon, 13 Apr 2009 23:23:56 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Apr 2009 16:23:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Apr 2009 16:23:55 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58070763E3@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <49E3ADA4.1090402@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard Thread-Index: Acm8fmx67kSpMh0eQy6uvI7c9DmPJAAAs1uA References: <20090402150706.EC83D28C222@core3.amsl.com> <49E3ADA4.1090402@gont.com.ar> From: "Anantha Ramaiah (ananth)" To: "Fernando Gont" , X-OriginalArrivalTime: 13 Apr 2009 23:23:56.0028 (UTC) FILETIME=[EA5F93C0:01C9BC8E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8559; t=1239665036; x=1240529036; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20Last=20Call=3A=20draft-ietf-tc pm-tcpsecure=20(Improving=20TCP's=20Robustness=20to=20Blind= 20In-Window=20Attacks)=20to=20Proposed=20Standard |Sender:=20; bh=W4TnDhGkfo4/yNzocGYS8jG4SM5azoQ4BD+4yVqYf2Q=; b=ARcD9u1fQ79xrHa1gt+QdUwurAlPKIMbVGPCUs6IBzIyBRNpRjPUMgIpga D8o2W/qsKiH078VJthjcH7h5N51mGcvbwuACHx2cZJ4isIRi53LFpyhEd7pn OFsujw0eZUN6sF7VfH4iWki6zXlD3NytLGIqwX/r8hCOaLa/SItXI=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard 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, 13 Apr 2009 23:22:46 -0000 Fernando, Thanks for you comments. Pl see responses inline :-=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Fernando Gont > Sent: Monday, April 13, 2009 2:25 PM > To: ietf@ietf.org > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure=20 > (Improving TCP's Robustness to Blind In-Window Attacks) to=20 > Proposed Standard >=20 > Folks, >=20 > Some last call comments: >=20 > * The document never mentions the fact that this document is=20 > IPR-encumbered. As far as I recall, much of the dicussion=20 > within tcpm with respect to the level of requirements of this=20 > document (MAY/SHOULD/MUST, etc.) had to do with this fact. I=20 > believe the document should include a warning mentioning that=20 > there's an IPR on the document, so that implementers can=20 > consider this point in their decision of whether to implement=20 > the described mechanisms or not. I am confused what to do since this is being brought up very late in the game. That said, there are *many* drafts/RFC's that have IPR on them in the whole of ietf. Do all them explicitly state the IPR link ? I'll leave it to the collective wisdom of the group and the chairs to offer guidance on this matter. >=20 > * The document discusses blind attacks, and to some extent=20 > assesses the difficulty in guessing the four-tuple that=20 > identifies a TCP connection. > However, it does not even mention port randomization, which=20 > is probably the most simple and straightforward approach for=20 > mitigating blind attacks against TCP. This was raised by me=20 Well, the point is that source port randomization is something external like Ipsec and nothing specfic to TCP. TCP will work with or without src port randomization. Now the scope of this document is to improve robustness to TCP esp. in cases where the TCP connection is not protected by other means like TCP MD5 or TCP AO etc., Now this point is very clear in the document. That said I have no issues putting a reference to the port randomization in the document. =20 > and other quite a few times in the tcpm wg list, pre and post=20 > wglc, but this comment was never addressed. It's particularly=20 > curious that port randomization is not mentioned when tsvwg=20 > is working on it (draft-ietf-tsvwg-port-randomization). Yes, you did raise this issue last time, but I did defer it to the WG and did not receive any response, so I simply left it at that. >=20 > * Among the factors that determine how easy these attacks be=20 > exploited is the window size. This document should provide,=20 > at the very least, pointers with advice on what to do with=20 > the tcp window. While quickly skimming through RFC 4953, it=20 It does mentions about the window size relationship, For example in the beginning sections of the document we briefly mention the window size and the # of packets that is required to generate a successful attack.=20 > seems it has some advice on the TCP window. We do offer a=20 > lengthy discussion of this and other issues in=20 > draft-gont-tcp-security and=20 > http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf >=20 > * Yet another factor is TCP ISN randomization. At the very=20 > least, this document could/should a pointer to RFC 1948. We=20 > do offer a lengthy discussion of this and other issues in=20 > draft-gont-tcp-security and=20 > http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf Why should it talk about ISN randomization since ISN randomization, is somewhat orthogonal to the type of attack here, it is not even one of the attack vector. We could refer this, but the scope of the current document is about the RST/SYN and Data attacks and mitigations, Since this document generally refers RFC 4953 (which came after this document was written. BTW) I think this should suffice, IMO. >=20 > * Just of the top of my head: Hadn't the BGP spec been=20 > updated so that a well-known port was not required as the=20 > *source* port? Not that I am aware of, I can look it up. >=20 > * The counter-measure of for the SYN-based reset attack may=20 > have missed a common heuristics for the handling of SYN=20 > segments. See pages 86 and > 87 of the UK CPNI paper on TCP security. FWIW, we argue that=20 > the processing of SYN segments proposed in [Ramaiah et al,=20 > 2008] should apply only for connections in any of the=20 > synchronized states other than the TIME-WAIT state. We just followed RFC 793 as the base and the changes are made w.r.t that. TIME-WAIT may be an exception but doesn't RFC 793 already has that language correct? >=20 > * When it comes to TCP-based blind-connection reset attacks,=20 > there's a much more trivial -- yet not discussed before? --=20 > alternative. See Section 11.1.3 and Section 11.1.4 in=20 > draft-gont-tcp-security and the CPNI paper=20 > (http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf). > These variants should, at the very least, be mentioned and a=20 > pointer provided to them as, at least in theory, are much=20 > easier to exploit. Those sounds like some new proposals (security and precedence) different stacks would have taken different measures to address this issue. Anyways this is something new and hence needs more discussion and evaluation. Has these ideas been submitted in a draft to TCPM? (your recent BCP document tcp-security, covers it ?) >=20 > * When it comes to the data injection attack, Michael=20 > Zalewski sketched another attack vector which may be easier=20 > to exploit. We discuss it in Section 16.2 of=20 > draft-gont-tcp-security and the CPNI doc, along with advice.=20 > IMO, this vector should be mentioned, too. This again is an attack which relies on the IP functionality and not TCP. For example the DF bit can be turned on then there is no fragmentation involved, in any case the current document is not intended as a protection for on-path attackers and not a complete solution for all kinds of off-path attacks (pl note the security considerations section). Also FWIW, our stacks already randomize IPID. Anyways these are clearly outside the scope of the current document, IMO. >=20 > Needless to say, I'm in favor of improving the robustness of=20 > TCP and, IPRs-aside, I'm happy with the implementation of the=20 > counter-measures described in the tcpsecure I-D (all three). Thanks. >=20 > I'm also glad that this doc is getting close to publication.=20 > Five years working on a document is quite a lot of time!=20 Agreed. Esp when it has been running in the internet with multiple vendors supporting these mitigations. -Anantha > (yes, it could have been worse, some might argue). >=20 > Thanks! >=20 > Kind regards, > Fernando Gont >=20 >=20 >=20 >=20 > The IESG wrote: > > The IESG has received a request from the TCP Maintenance and Minor=20 > > Extensions WG (tcpm) to consider the following document: > >=20 > > - 'Improving TCP's Robustness to Blind In-Window Attacks ' > > as a Proposed Standard > >=20 > > The IESG plans to make a decision in the next few weeks,=20 > and solicits=20 > > final comments on this action. Please send substantive comments to=20 > > the ietf@ietf.org mailing lists by 2009-04-16.=20 > Exceptionally, comments=20 > > may be sent to iesg@ietf.org instead. In either case, please retain=20 > > the beginning of the Subject line to allow automated sorting. > >=20 > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-11.txt > >=20 > >=20 > > IESG discussion can be tracked via > >=20 > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTa > > g=3D11735&rfc_flag=3D0 > >=20 > > The following IPR Declarations may be related to this I-D: > >=20 > > https://datatracker.ietf.org/ipr/421/ > >=20 > >=20 > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > >=20 >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org PGP=20 > Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From fernando.gont.netbook.win@gmail.com Mon Apr 13 22:43:31 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761FD3A6D99; Mon, 13 Apr 2009 22:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 sCSbgW+hjeUV; Mon, 13 Apr 2009 22:43:30 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.241]) by core3.amsl.com (Postfix) with ESMTP id 994FF3A6D97; Mon, 13 Apr 2009 22:43:29 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 23so1116653agd.12 for ; Mon, 13 Apr 2009 22:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=4r6fJ2HYuYJwLMrCqOfC7vCje8jq+inqAyUc/bkP2sY=; b=DQFayMU3ciGL29pGCYmGerPRVI7Ggym28+WJ9vnLB7x9Kfs4g0ZrMC9B8v77N8jb85 MiDPuq6nfsUwCmUuXTO/0QUiXYOQYu32H3GWfqd5WdhSBsPXVm+MCEVkRSY0n9Pcrx4h 8to77Jfnc2DY+CC+MsV2zCdrj5BGO4Q6oIa6E= 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=cpvBW2J6mIRx+LL/cUc/rw+vmAkDJ+ZwWd08pBIQruqkGb2FA+EVEz6JIbQLwjLhWX eA1XRlaOsNdgevgRKW5dAMDUNFdc42XYhenDDUu79ZQXL9om8rsUjI/nTFgE23iT7Tuj 81dcmdy02OsXoZyyR6IY6BLyx5YpYbDH+JHyA= Received: by 10.90.117.17 with SMTP id p17mr491548agc.30.1239687880210; Mon, 13 Apr 2009 22:44:40 -0700 (PDT) Received: from ?192.168.1.3? ([190.50.221.185]) by mx.google.com with ESMTPS id 34sm1197628agc.39.2009.04.13.22.44.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 22:44:39 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E422C0.5050908@gont.com.ar> Date: Tue, 14 Apr 2009 02:44:32 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Joe Touch References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> In-Reply-To: <49E3BED9.1030701@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , "Smith, Donald" , 'Joe Abley' , "'opsec@ietf.org'" Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 14 Apr 2009 05:43:31 -0000 Joe Touch wrote: >>>> The consensus seems to be that the current state of affairs is something >>>> like: "a mess". Even if you do care to produce a resilient >>>> implementation, that task is going to be much harder than necessary. You >>>> don't know the amount of cycles we spent in producing >>>> draft-gont-tcp-security.... let alone the time it would take to move the >>>> advice in an actual implementation. >>> Advice in making a hardened version of TCP would be useful to the >>> implementation community. >> To a large extent this is what draft-gont-tcp-security is about. > > Implementation advice is outside the scope of the IETF. It's not even > operational, IMO. RFC 816: "MODULARITY AND EFFICIENCY IN PROTOCOL IMPLEMENTATION" RFC 815: "IP DATAGRAM REASSEMBLY ALGORITHMS" (see Section 4) and, RFC 1936: "Implementing the Internet Checksum in Hardware" (of which you are on of the co-authors :-) ) That said, to a large extent the document is provides advise about enforcing stricter validation checks, timeouts where appropriate, and about a number of policies that may improve TCP's resiliency/security (e.g., how to select ISN's, etc.) >>> You've produced a summary of issues you feel would harden TCP. I feel >>> that some of them make TCP more brittle, and some make TCP unnecessarily >>> complex, and in both cases the mods are not needed in the general >>> Internet. >> Is there nothing in the document with which you agree? > > That'd be harsh. I agree with some of the implementation advice as > implementation advice. I agree that, in risk-prone environments (where > packets can be tapped, e.g.), some of the recommendations are appropriate. > > I'm disagreeing primarily with the general tone and balance of the document. I believe at this point in time we're deciding whether it makes sense to work on this document, and where it would make sense to do it. draft-gont-tcp-security-00 is just a starting point. Of course, it represents my pov, and to some extent the pov of the reviewers. But the idea of bringing it to the IETF is that future versions of the document represent wg consensus. If you have specific suggestions on how to improve the document, I'll be more than happy to hear about them. However, I believe at this point we are not yet discussing on any specific issue discussed in the draft, but are trying to agree on how to move forward. (Feedback on the technical details in the document is nevertheless welcome, though) >> c'mon Joe.. IMO, tcpsecure needed to include those statements about >> usefulness in large part because it was IPR-encumbered, and in part as a >> political workaround that would avoid further waste of time in endless >> discussions. > > I disagree. Even if it weren't IPR encumbered, I would disagree with > widescale deployment of a modification to TCP that answers a RST with > one *or more* ACKs. As I said numerous times w.r.t. that document, the > modifications it suggests are generally not needed, unnecessarily > complicate packet processing, and since they don't protect from > in-window injection attacks, I find them useless in the general case. TCP is already very complicated. And the implementation of the countermeasures in tcpsecure usually require not much more than (literally) a couple of additional lines, or a slight modification in some conditional statement. >>>> It becomes harder to get s staright answer when it's impossible for a >>>> vendor to point to a counter-measure that is supposed to be the result >>>> of a thorough review process, in a *timely* fashion. >>> Can you be as specific here as you want us to be? What exactly does a >>> vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing >>> known countermeasures? >> What's "the existing known counter-measures"? > > Limit cycles/resources available for new connections, e.g., for SYN > attacks -- as is already done for things like IKE. At the point in which you actually try to put this into code, a number of questions arise that need to be answered. Why should vendors rehash the same analysis over an over again (with the potential of doing it wrong, which would lead to buggy implementations), when we could put out a document with consensus on the preferable way to do those things. >> FWIW, vendors are following the UK CPNI document. The idea of bringing >> those results to the IETF is so that these results/advice can be further >> discussed, more eyes look into them, and the doc is modified if it is >> felt necessary. > > I've been saying I feel that mods are necessary, and you keep > complaining. That's not how I read your comments. If your point of view is "it would be interesting to work on this. however, i believe the document should be modified in this way, because of this reason" that's one thing. If your pov is "we don't need this. go somewhere else", that's something entirely different. > If you're here for a rubber stamp, you came to the wrong WG ;-) Rubber-stamp? No, Joe. The UK CPNI rubberstamp is more than enough, and when it comes to advice on this issues, I believe it's even more credible. Ask the question in bugtraq or full-disclosure, and that's most likely the conclusion you'll get to. I'm involved in the IETF, and honestly believe that the IETF should work on this. I do know that the end result of that process would be such that I probably won't be as happy with the resulting RFC than with the UK CPNI document. But at least I would have helped to change the current state of affairs a little bit. > The sky has been falling in this WG for several years. Although this > document is the first aggregation of such recommendations, as you know > it's composed of many documents you yourself have been discussing for > that period in this WG.. I'd probably argue that the case with tcpm is that at (many) times protocol specifications have been taken as if they were casted in stone. And unless one is part of some small circle of people that is supposed to have been allowed by God to modify such specs, it will be very hard there's no effort that takes less than quite a few years. Very loud people take the time to maintain endless discussions, and most mere mortals that need to get work done end up completely avoiding tcpm altogether, because it requires a huge spend of time. Virtually every developer that I know of won't care about what the end result in tcpm is. At most, they will post a question to hear comments. But that's it. To a large extent people cannot believe the amount of energy we spend for such a null progress. Example: ICMP attacks draft (draft-ietf-tcpm-icmp-attacks). The doc was reviewed by devolpers from Sun, FreeBSD, NetBSD, OpenBSD, Linux, extreme networks, and Cisco (this last one "unofficially"). To them, the draft looks okay. Many other people have also agreed with that. But I cannot get those folks involved in our endless discussions. The ROI for them is NULL. Do they care about the outcome? Not really. They agree with the proposal, it is in the code already, and has been running for years. They just let us waste our time. I agree that there are benefits to be gained from having a more conservative philosophy, to put it some way. I believe that it is a good thing to challenge proposals, to aim at improving their quality, etc. This has helped improve many documents, including those I have authored. But I believe at some point it starts looking as "everything that neither me or my inner circle proposes will be banned". >> Honestly, I'm not sure why you always have to knock down others' efforts >> on a "by default" basis, and prejudge the motivation behind those efforts. > > I'm asking the question I apparently keep needing to ask: > > Why do you think that just because something is implemented > we should recommend it? That's not how the tcp-security document was produced. For instance, many of the recommendations had never been implemented. And the document argues *against* some common implementation strategies. > Why do you think that a message that isn't expected indicates > an attack to be defended against, vs. the actions of a > benign endpoint? We simply raise the bar about what we react to. If there are packets for which there's no legitimate use, we don't react to them (if this doesn't cause harm). > I have a high bar for the need for modifications to TCP, and the need to > propagate local solutions to every endpoint in the Internet. And do you believe that such propagation depends on our outcome? -- Thanks God, it doesn't. Try to find any implementation that is fully-compliant with the RFCs, and let me know if you find any. The lack of advice on all these issues has put vendors in a position in which they have to figure out that advice by themselves. Sometimes they got to the right answers, sometimes not. Have a look at the vulnerability advisories referenced in the I-D: the same errors are committed over and over again. draft-gont-tcp-security is an effort to help the vendor/developer community in that area. P.S.: My apologizes for the possible politically-incorrect comments. But this is the best trade-off I have been able to get between being politically-correct and being honest. Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From lars.eggert@nokia.com Tue Apr 14 00:54:57 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062103A6D6B; Tue, 14 Apr 2009 00:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tG5KGQn5-JwY; Tue, 14 Apr 2009 00:54:56 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 4DFC13A68AC; Tue, 14 Apr 2009 00:54:55 -0700 (PDT) Received: from [10.180.41.39] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3E7tlVr021648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Apr 2009 10:55:47 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Joe Touch In-Reply-To: <49E3BED9.1030701@isi.edu> Content-Type: multipart/signed; boundary=Apple-Mail-28--604463031; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 10:55:41 +0300 References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Tue, 14 Apr 2009 10:55:49 +0300 (EEST) Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , "Smith, Donald" , 'Joe Abley' , "'opsec@ietf.org'" , Fernando Gont Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 14 Apr 2009 07:54:57 -0000 --Apple-Mail-28--604463031 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-4-14, at 1:38, Joe Touch wrote: >>> Advice in making a hardened version of TCP would be useful to the >>> implementation community. >> >> To a large extent this is what draft-gont-tcp-security is about. > > Implementation advice is outside the scope of the IETF. It's not even > operational, IMO. I do believe there is value in having a document that would inform a stack vendor of various potential attack vectors against a TCP stack and what techniques exist to harden their stacks. I agree with Joe that some of the hardening techniques that vendors are implementing come with consequences (make TCP more brittle). To me, this is a *reason* this document should be published via the IETF (i.e., TCPM) - we are probably in the best position to correctly evaluate and classify the impact of various hardening techniques. Stack vendors have been putting these mechanisms in to their stacks without clear specifications and discussions of the potential upsides and downsides that would let them make an educated decision. It seems clear to me that the vendor community is looking for guidance here, and I do believe the IETF should give it. Yes, there is a fine line here, where some of the hardening techniques introduce some new assumptions on what the segment flow of a valid connection looks like, etc. It will be important to accurately describe the downsides of some of these techniques, especially where they could result in valid connections being dropped. Lars --Apple-Mail-28--604463031 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MTQwNzU1NDJaMCMGCSqGSIb3DQEJBDEWBBREqH3+Yywn6SkM ypipqjJrdrfJyzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAefcwn9J83NjbayLSfmaOtmOQIA8WYa2t4Z9IcLUviG+OlmZj5CdY L1D9ATmCChbP/0aJ1hi1rl57gkoJLeHVjwIT19AhHriv6bfukiNn+aiIr4HFjJobMwfFmw5muwi+ ObIPr7KZxKlwVhcepSL1iC1/LsAi6t1yGKDyqVoTNTJnlw9jjxT8z4Inu+KL7QTGIAcrh9PeKcoP Emxo5XEa3tR//A5Ie7LmRqOADOOz3OhhEiQ3Cry1iPFydvQDJOl2/aYAidtBT7jcsrwmBqENPa+c gxIJB4r3bU+Bt4pQ+H+AEx94oErvwD4sUL02V8Q00xEHMnMBziKtrMRV8A74CAAAAAAAAA== --Apple-Mail-28--604463031-- From touch@ISI.EDU Tue Apr 14 07:19:58 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B20728C13C; Tue, 14 Apr 2009 07:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 GQO0U+JHeIaL; Tue, 14 Apr 2009 07:19:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BBE4E3A6DE3; Tue, 14 Apr 2009 07:19:56 -0700 (PDT) Received: from [192.168.1.44] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3EEKSc2024923; Tue, 14 Apr 2009 07:20:30 -0700 (PDT) Message-ID: <49E49BAC.8000300@isi.edu> Date: Tue, 14 Apr 2009 07:20:28 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fernando Gont References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <49E422C0.5050908@gont.com.ar> In-Reply-To: <49E422C0.5050908@gont.com.ar> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , "Smith, Donald" , 'Joe Abley' , "'opsec@ietf.org'" Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 14 Apr 2009 14:19:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>>>> The consensus seems to be that the current state of affairs is something >>>>> like: "a mess". Even if you do care to produce a resilient >>>>> implementation, that task is going to be much harder than necessary. You >>>>> don't know the amount of cycles we spent in producing >>>>> draft-gont-tcp-security.... let alone the time it would take to move the >>>>> advice in an actual implementation. >>>> Advice in making a hardened version of TCP would be useful to the >>>> implementation community. >>> To a large extent this is what draft-gont-tcp-security is about. >> Implementation advice is outside the scope of the IETF. It's not even >> operational, IMO. > > RFC 816: "MODULARITY AND EFFICIENCY IN PROTOCOL IMPLEMENTATION" > RFC 815: "IP DATAGRAM REASSEMBLY ALGORITHMS" (see Section 4) > > and, > > RFC 1936: "Implementing the Internet Checksum in Hardware" (of which you > are on of the co-authors :-) ) Those are informational, you will note. > That said, to a large extent the document is provides advise about > enforcing stricter validation checks, timeouts where appropriate, and > about a number of policies that may improve TCP's resiliency/security > (e.g., how to select ISN's, etc.) Those 'validation checks' aren't validations when they exceed the TCP specifications. >>>> You've produced a summary of issues you feel would harden TCP. I feel >>>> that some of them make TCP more brittle, and some make TCP unnecessarily >>>> complex, and in both cases the mods are not needed in the general >>>> Internet. >>> Is there nothing in the document with which you agree? >> That'd be harsh. I agree with some of the implementation advice as >> implementation advice. I agree that, in risk-prone environments (where >> packets can be tapped, e.g.), some of the recommendations are appropriate. >> >> I'm disagreeing primarily with the general tone and balance of the document. > > I believe at this point in time we're deciding whether it makes sense to > work on this document, and where it would make sense to do it. > draft-gont-tcp-security-00 is just a starting point. Of course, it > represents my pov, and to some extent the pov of the reviewers. But the > idea of bringing it to the IETF is that future versions of the document > represent wg consensus. > > If you have specific suggestions on how to improve the document, I'll be > more than happy to hear about them. > > However, I believe at this point we are not yet discussing on any > specific issue discussed in the draft, but are trying to agree on how to > move forward. (Feedback on the technical details in the document is > nevertheless welcome, though) Agreed. I'm suggesting that there are several possible documents, with different possible 'homes': 1. a document that focuses on implementing a hardened TCP that is outside the scope of the IETF, esp. where it exceeds IETF recommendations for modifications to TCP 2. a document that summarizes and streamlines TCP modifications i.e., this would be somewhat like a 793-bis; that's a huge undertaking, and would belong in TSVWG rather than TCPM If this document is intended to be an IETF product, rather than an informational individual contribution, it needs to reflect IETF consensus. >>> c'mon Joe.. IMO, tcpsecure needed to include those statements about >>> usefulness in large part because it was IPR-encumbered, and in part as a >>> political workaround that would avoid further waste of time in endless >>> discussions. >> I disagree. Even if it weren't IPR encumbered, I would disagree with >> widescale deployment of a modification to TCP that answers a RST with >> one *or more* ACKs. As I said numerous times w.r.t. that document, the >> modifications it suggests are generally not needed, unnecessarily >> complicate packet processing, and since they don't protect from >> in-window injection attacks, I find them useless in the general case. > > TCP is already very complicated. And the implementation of the > countermeasures in tcpsecure usually require not much more than > (literally) a couple of additional lines, or a slight modification in > some conditional statement. The number of lines alone does not reflect the complexity issue; the way it complicates interactions is. >>>>> It becomes harder to get s staright answer when it's impossible for a >>>>> vendor to point to a counter-measure that is supposed to be the result >>>>> of a thorough review process, in a *timely* fashion. >>>> Can you be as specific here as you want us to be? What exactly does a >>>> vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing >>>> known countermeasures? >>> What's "the existing known counter-measures"? >> Limit cycles/resources available for new connections, e.g., for SYN >> attacks -- as is already done for things like IKE. > > At the point in which you actually try to put this into code, a number > of questions arise that need to be answered. Why should vendors rehash > the same analysis over an over again (with the potential of doing it > wrong, which would lead to buggy implementations), when we could put out > a document with consensus on the preferable way to do those things. Showing a way to do something is useful; claiming it is preferred requires consensus. The IETF doesn't specify preferred implementations; it does give them as examples, but they tend to be in informational individual documents rather than as WG product. >>> FWIW, vendors are following the UK CPNI document. The idea of bringing >>> those results to the IETF is so that these results/advice can be further >>> discussed, more eyes look into them, and the doc is modified if it is >>> felt necessary. >> I've been saying I feel that mods are necessary, and you keep >> complaining. > > That's not how I read your comments. If your point of view is "it would > be interesting to work on this. however, i believe the document should > be modified in this way, because of this reason" that's one thing. > > If your pov is "we don't need this. go somewhere else", that's something > entirely different. IMO, the IETF doesn't need to spend group cycles to work on how to implement TCP efficiently or in safe ways. That's software engineering, and may be a good idea or even a good individual submission, but not what I think of as WG effort. If this doc is intended to be a WG product, it needs to focus on reflecting IETF consensus and recommendations. Its current focus is "what is implemented", as if that is sufficient rationale. ... >> The sky has been falling in this WG for several years. Although this >> document is the first aggregation of such recommendations, as you know >> it's composed of many documents you yourself have been discussing for >> that period in this WG.. > > I'd probably argue that the case with tcpm is that at (many) times > protocol specifications have been taken as if they were casted in stone. > And unless one is part of some small circle of people that is supposed > to have been allowed by God to modify such specs, it will be very hard > there's no effort that takes less than quite a few years. We are conservative. We're talking about changes that affect the core of the Internet, so that is appropriate. Whether a modification is accepted as standards track or not is based on whether it is **generally** needed, not whether it has been implemented or even deployed. I'm not quite sure of what small circle you're referring to, but the primary mods to the standards track over the past few years have been in ways that were supported by a large pile of analysis, e.g., increasing TCP's initial window. When people come without that pile, they're challenged. A pile of code is not a substitute for a pile of analysis. > Very loud people take the time to maintain endless discussions, and most > mere mortals that need to get work done end up completely avoiding tcpm > altogether, because it requires a huge spend of time. > > Virtually every developer that I know of won't care about what the end > result in tcpm is. At most, they will post a question to hear comments. > But that's it. To a large extent people cannot believe the amount of > energy we spend for such a null progress. > > Example: ICMP attacks draft (draft-ietf-tcpm-icmp-attacks). > The doc was reviewed by devolpers from Sun, FreeBSD, NetBSD, OpenBSD, > Linux, extreme networks, and Cisco (this last one "unofficially"). To > them, the draft looks okay. Many other people have also agreed with > that. But I cannot get those folks involved in our endless discussions. > The ROI for them is NULL. > > Do they care about the outcome? Not really. They agree with the > proposal, it is in the code already, and has been running for years. > They just let us waste our time. > > I agree that there are benefits to be gained from having a more > conservative philosophy, to put it some way. I believe that it is a good > thing to challenge proposals, to aim at improving their quality, etc. > This has helped improve many documents, including those I have authored. > But I believe at some point it starts looking as "everything that > neither me or my inner circle proposes will be banned". TCPM exists as much to protect TCP from tweaking as it is to mature proposed tweaks. The more tweaks anyone proposes, the more they get challenged. The less analysis behind the proposals, the more they get challenged. Deployed code is not a substitute for analysis. It's unfortunate if you feel personally affected by that approach, but it's simply cause and effect. **ALL** documents in this WG are challenged, and the bar in this WG is higher than in other WGs - and it should be. If your goal is making progress more quickly, you need to create your own protocol to modify. >>> Honestly, I'm not sure why you always have to knock down others' efforts >>> on a "by default" basis, and prejudge the motivation behind those efforts. >> I'm asking the question I apparently keep needing to ask: >> >> Why do you think that just because something is implemented >> we should recommend it? > > That's not how the tcp-security document was produced. For instance, > many of the recommendations had never been implemented. And the document > argues *against* some common implementation strategies. Agreed; those are not the parts I'm as concerned with. >> Why do you think that a message that isn't expected indicates >> an attack to be defended against, vs. the actions of a >> benign endpoint? > > We simply raise the bar about what we react to. If there are packets for > which there's no legitimate use, we don't react to them (if this doesn't > cause harm). When a packet arrives that *could* have been legitimate, i.e., for which there is *any* legitimate use, you have an obligation to react to it. I don't agree that some of what you're proposing takes this into account. >> I have a high bar for the need for modifications to TCP, and the need to >> propagate local solutions to every endpoint in the Internet. > > And do you believe that such propagation depends on our outcome? -- > Thanks God, it doesn't. Try to find any implementation that is > fully-compliant with the RFCs, and let me know if you find any. > > The lack of advice on all these issues has put vendors in a position in > which they have to figure out that advice by themselves. Sometimes they > got to the right answers, sometimes not. > > Have a look at the vulnerability advisories referenced in the I-D: the > same errors are committed over and over again. > > draft-gont-tcp-security is an effort to help the vendor/developer > community in that area. I agree that vendors need some sort of implementation advice. I don't agree that the IETF needs to be the place where that is made. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknkm6wACgkQE5f5cImnZrsZbQCg4F5I57j8Zz/wTSsnjfN7dhrx tqMAoNaM+MmXCJc6yvsvwXUc52cn+ZaB =9V8t -----END PGP SIGNATURE----- From touch@ISI.EDU Tue Apr 14 07:25:28 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A407B28C143; Tue, 14 Apr 2009 07:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 gENXVAnQgmN8; Tue, 14 Apr 2009 07:25:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7ABF028C102; Tue, 14 Apr 2009 07:25:12 -0700 (PDT) Received: from [192.168.1.44] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3EEPqfj026073; Tue, 14 Apr 2009 07:25:54 -0700 (PDT) Message-ID: <49E49CF0.6070203@isi.edu> Date: Tue, 14 Apr 2009 07:25:52 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Yiu L. Lee" References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: softwires@ietf.org, tcpm@ietf.org Subject: Re: [tcpm] [Softwires] TCP MSS clamping to try to deal with MTU issues in Dual-Stack Lite 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, 14 Apr 2009 14:25:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yiu L. Lee wrote: > HI Joe, > > In RFC2385 - Section 2.0 Item 2, it says > > 2. the TCP header, excluding options, and assuming a checksum of > zero > > Since TCP options are excluded, changing MSS won't affect the MD5 mechanism, > will it? In TCP MD5, TCP options can be modified and the MD5 hash will not detect it. > In draft-ietf-tpcm-tcp-auth-opt-04.txt - Section 5 Item 2, it says > > 2. A TCP option flag. When 0, this flag allows default operation, > i.e., TCP options are included in the MAC calculation, with TCP- > AO's MAC field zeroed out. When 1, all options (excluding TCP-AO) > are excluded from all MAC calculations (skipped over, not simply > zeroed). The option flag applies to TCP options in both directions > (incoming and outgoing segments). > > >> The TCP option flag MUST NOT change during a TCP connection. > > The TCP option flag cannot change during a connection because TCP > state is coordinated during connection establishment. TCP lacks a > handshake for modifying that state after a connection has been > established. > > Changing MSS could be a problem when TCP option flag is set to 0. When the > flag is set to 1, changing MSS is fine, isn't it? Yes, these are correct. I would assume that the flag is 0, however - there are numerous reasons to want/need to protect other TCP options, e.g., timestamps, to protect the connection from attack. Joe > On 4/7/09 6:54 PM, "Joe Touch" wrote: > > Hi, all, > > The solution has a bug: if TCP traffic uses TCP MD5 or TCP-AO, then it > needs to be handled like non-TCP traffic, since MSS revision would > destroy the packet's integrity. > > IMO, this should be handled the simple way - remove the TCP case, and > handle all traffic the non-TCP way. > > Finally, if a NAT ever refuses to reassemble anything, it MUST issue an > ICMP too-big IMO. The whole idea of creating a problem (encapsulating, > decreasing the effective MSS on a path) then not cleaning it up > yourself, or deciding when to clean it up based on *current* assumptions > of network traffic is a bad idea and shouldn't be supported. > > Joe > > Magnus Westerlund wrote: >>>> Hi, >>>> >>>> There is a proposal to use TCP MSS clamping to deal with MTU issues that >>>> comes from Dual-stack lite's tunnel encapsulation. >>>> >>>> I think it would be good if TCPM could provide some feedback on this >>>> proposal. >>>> >>>> The relevant document and section: >>>> http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-00 >>>> >>>> 7.4. MTU >>>> >>>> >>>> Using an encapsulation (IP in IP or L2TP) to carry IPv4 traffic over >>>> IPv6 will reduce the effective MTU of the datagrams. Unfortunately, >>>> path MTU discovery is not a reliable method to deal with this. As >>>> such a combination of solutions is suggested: >>>> >>>> o For TCP traffic, let the carrier-grade NAT rewrite the MSS in the >>>> first SYN packet to a lower value. >>>> >>>> o For non-TCP traffic, perform fragmentation and reassembly over the >>>> tunnel between the home gateway and the carrier grade NAT. In >>>> practice, this means put the IPv4 packet into a large IPv6 packet >>>> and fragment/reassemble the IPv6 packet at each endpoint of the >>>> tunnel. There is a performance price to pay for this. >>>> Fragmentation is not very expensive, but reassembly can be, >>>> especially on the carrier-grade NAT that would have to keep track >>>> of a lot of flows. However, such a carrier-grade NAT would only >>>> have to perform reassembly for large UDP packets sourced by >>>> customers, not for large UDP packets received by customers. In >>>> other words, streaming video to a customer would not have a >>>> significant impact on the performance of the carrier-grade NAT, >>>> but will require more work on the home gateway side. >>>> >>>> Cheers >>>> >>>> Magnus Westerlund >>>> >>>> IETF Transport Area Director & TSVWG Chair >>>> ---------------------------------------------------------------------- >>>> Multimedia Technologies, Ericsson Research EAB/TVM >>>> ---------------------------------------------------------------------- >>>> Ericsson AB | Phone +46 10 7148287 >>>> Färögatan 6 | Mobile +46 73 0949079 >>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>>> ---------------------------------------------------------------------- >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknknO8ACgkQE5f5cImnZrv7owCghgf+Mq4n0Oth93iaA3mPLkO6 2jcAoKcufMum39GbkG3rMhG/WD5BlE1c =kvbr -----END PGP SIGNATURE----- From Donald.Smith@qwest.com Mon Apr 13 12:54:48 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7367928C156; Mon, 13 Apr 2009 12:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n59JO5OSrqrS; Mon, 13 Apr 2009 12:54:35 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id E180728C152; Mon, 13 Apr 2009 12:54:34 -0700 (PDT) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id n3DJte07020122; Mon, 13 Apr 2009 13:55:40 -0600 (MDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.0/8.14.0) with ESMTP id n3DJtX9g000470; Mon, 13 Apr 2009 14:55:34 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Mon, 13 Apr 2009 13:55:30 -0600 From: "Smith, Donald" To: "'Fernando Gont'" , "'Joe Touch'" Date: Mon, 13 Apr 2009 13:55:30 -0600 Thread-Topic: [OPSEC] [tcpm] draft-gont-tcp-security Thread-Index: Acm8bWCAc1S4KexUSCS6Tc+o0uRA6wAAO68A Message-ID: References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> In-Reply-To: <49E39119.1060902@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-Mailman-Approved-At: Tue, 14 Apr 2009 08:24:13 -0700 Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 13 Apr 2009 19:54:48 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org]=20 > On Behalf Of Fernando Gont > Sent: Monday, April 13, 2009 1:23 PM > To: Joe Touch > Cc: tcpm@ietf.org; ietf@ietf.org; Joe Abley; opsec@ietf.org;=20 > Lars Eggert; Eddy,Wesley M. (GRC-RCN0)[Verizon] > Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security >=20 > Joe Touch wrote: >=20 > >> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a > >> trivial attack in 2008 (Outpost24/CERT-FI), and we'll=20 > probably continue > >> in this line, because we do nothing about it. > >=20 > > Whether we have this document or not, we will continue to=20 > have people > > who incorrectly assume that TCP is secure. Secure is a general term. TCP was intended to address several areas of secu= rity. The classic tenets for computer security is: CIA -> Confidentiality, Integrity and Availability. TCP doesn't attempt to address Confidentiality. However it was designed to address integrity and availability so failures i= n those areas should be documented and addressed in some fashion. >=20 > That's correct. But we also have people that do know it is not mean to > be secure, but that it should be resilient enough so that it's still > usable. One way or another, most stacks implement counter-measures for > SYN-floods (on which tcpm did publish something), timers on the > FIN-WAIT-2 state, port randomization (on which tsvwg is working), ICP > ISN randomization, etc. >=20 > The reason for which they did that was to improve TCP's=20 > security/resiliency. >=20 > Would you argue in favour of predictable ISNs, predictable ports, > time-less FIN-WAIT-2 state, etc.? -- I hope you wouldn't. >=20 >=20 >=20 > >>> It summarizes issues already raised by the WG,=20 > >> I believe this statement is unfair with respect to our=20 > document. e.g., > >> has the issues described in Section 4.3, Section 9.2, or=20 > Section 10 been > >> brought to tcpm before??? > >=20 > > I didn't say that's all it does ;-) Agreed that it raises=20 > other issues, > > many of which are operational. >=20 > Many of which arise if you expect to use TCP in some other=20 > scenario that > just two computers in a LAN. If that makes those issues=20 > "operational", I > agree. >=20 >=20 >=20 > >>> TCP itself is not a secure protocol, nor is it intended to be. Again, it was intended to help ensure integrity and availability. > >> Yeah. But that does not mean that we should not do our=20 > best to improve > >> it. > >=20 > > It means we should not try to give the incorrect impression that it > > *can* be secured.=20 It can be made better that is not an incorrect impression it is a fact. >=20 > It's security/resiliency can be improved. After all, if that were not > the case, I guess you're wasting your time with TCP-AO. Or is it that > you believe the only way to improve a protocol is to throw=20 > crypto at it? Adding crypto improves confidentiality and integrity but is counter product= ive to availability as most=20 crypto engines are prone to fairly low pps resource exhaustion attacks. =20 >=20 > > Interpreting every unexpected event as an attack makes=20 > > a protocol robust but also brittle; TCP is intended to=20 > trade flexibility > > for security, AFAICT, because it is agnostic about intent,=20 > and gives the > > benefit of doubt at all times.=20 >=20 > I would prefer that instead of making this type of broad=20 > statement, you > would argue against a particular recommendation in > draft-gont-tcp-security, and explain how it makes TCP more brittle. >=20 >=20 >=20 > > Consider packet drops. That can happen due to loss, non-malicious > > corruption, or jamming, e.g. In the last case, it makes=20 > sense to blast > > copies of packets in the hopes of getting something=20 > through, but that's > > NOT what we assume. >=20 > Wasn't this very behavior what lead to the Internet=20 > congestion collapse > in the 80's, or am I missing something? >=20 >=20 >=20 > >> Please talk to vendors. I don't want to reproduce here=20 > what seems to > >> be the consensus among vendors with respect to the current state of > >> affairs in terms of how up-to-date our specs are. I talk to vendors a lot. I don't think there is a consensus on the "how up-= to-date our specs are". I can't even get a straight answer on how they addressed the icmp-blind res= ets or the tcp-blind resets from several years ago. There were several poss= ible mitigations with some trade offs on each of them. Yet finding out how = your favorite vendor addressed those is likely to be difficult. > >=20 > > Vendors misapply our protocols then complain that they=20 > don't work. Yes, > > there are operational issues, but one severe operational=20 > issue is not > > using security for some policy, financial, or operation=20 > expense and then > > complaining that nonsecure TCP is being attacked. Again the use of a generic "secure". What do you mean by "nonsecure" here? >=20 > Joe, we're talkng about a simple web server being taken down=20 > because of > a SYN flood, a FIN-WAIT-2 flood, or the like. Even the most stupid web > server should survive these types of attacks. >=20 > Kind regards, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > = From Donald.Smith@qwest.com Mon Apr 13 15:03:33 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A456C3A6A13; Mon, 13 Apr 2009 15:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hq0TbDwxBTt; Mon, 13 Apr 2009 15:03:32 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id A0B943A68A8; Mon, 13 Apr 2009 15:03:32 -0700 (PDT) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id n3DM4IhI001293; Mon, 13 Apr 2009 17:04:19 -0500 (CDT) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id n3DM4CaU024708; Mon, 13 Apr 2009 17:04:12 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Mon, 13 Apr 2009 16:04:12 -0600 From: "Smith, Donald" To: "'Joe Touch'" Date: Mon, 13 Apr 2009 16:04:11 -0600 Thread-Topic: [OPSEC] [tcpm] draft-gont-tcp-security Thread-Index: Acm8fCTNNWHKB3L4SN2ay+XPh46BiwAAxQwg Message-ID: References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A9D6.4030504@isi.edu> In-Reply-To: <49E3A9D6.4030504@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 14 Apr 2009 08:24:13 -0700 Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Fernando Gont' Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 13 Apr 2009 22:03:33 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Monday, April 13, 2009 3:09 PM > To: Smith, Donald > Cc: 'Fernando Gont'; 'tcpm@ietf.org'; 'ietf@ietf.org'; 'Joe=20 > Abley'; 'opsec@ietf.org'; 'Lars Eggert'; 'Eddy,Wesley M.=20 > (GRC-RCN0)[Verizon]' > Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Donald, >=20 > I'm confused by your post. You appear to believe that TCP is=20 > intended to > be secure. Note that TCP does not require either the MD5 or=20 > AO extension. I didn't mentioned authentication or authorization in my description of sec= urity but those two enhancements do provide some ability for authentication and authorizati= on. Yes, I do think elements of tcp/ip were designed to address the integrity a= nd availablity. >=20 > Smith, Donald wrote: > >=20 > > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > > Donald.Smith@qwest.com gcia =20 > >=20 > >> -----Original Message----- > >> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org]=20 > >> On Behalf Of Fernando Gont > >> Sent: Monday, April 13, 2009 1:23 PM > >> To: Joe Touch > >> Cc: tcpm@ietf.org; ietf@ietf.org; Joe Abley; opsec@ietf.org;=20 > >> Lars Eggert; Eddy,Wesley M. (GRC-RCN0)[Verizon] > >> Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security > >> > >> Joe Touch wrote: > >> > >>>> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a > >>>> trivial attack in 2008 (Outpost24/CERT-FI), and we'll=20 > >> probably continue > >>>> in this line, because we do nothing about it. > >>> Whether we have this document or not, we will continue to=20 > >> have people > >>> who incorrectly assume that TCP is secure. > >=20 > > Secure is a general term. TCP was intended to address=20 > several areas of security. > > The classic tenets for computer security is: > > CIA -> Confidentiality, Integrity and Availability. > > TCP doesn't attempt to address Confidentiality. > > However it was designed to address integrity and availability so=20 > > failures in those areas should be documented and addressed in some > > fashion. >=20 > Can you explain this? Where is the integrity protection? Where is the > availability specified? Checksumming in tcp/ip is intended to provide intregrity protection. Mind you it is NOT tamper proof but that is the intent. Detection of lost packets, retransmitions, reassembly of fragments, congest= ion notification, dynamic routing and many other tcp/ip features are intend= ed to address availablity. >=20 > ... > >> It's security/resiliency can be improved. After all, if=20 > that were not > >> the case, I guess you're wasting your time with TCP-AO. Or=20 > is it that > >> you believe the only way to improve a protocol is to throw=20 > >> crypto at it? > >=20 > > Adding crypto improves confidentiality and integrity but is counter > > productive to availability as most > > crypto engines are prone to fairly low pps resource exhaustion > > attacks. >=20 > All prevention methods are susceptible to computational resource > attacks, since all increase the operations performed on a=20 > packet.=20 GTSM is a valuable exception to this statement but other then that I tend t= o agree:) >It is > commonly assumed that this is a desirable tradeoff, and that the > computational resources can be totally protected with line-rate > dedicated computation (e.g., hardware assist). I believe that is a common assumption however I don't believe that assumpti= on is correct. I do a fair amount of router testing and although some portions of ipv4 are= hardware assisted and therefore line-rate there are still many paths to th= e "slow path". IPv6 has many more routes to the slow path:( >=20 > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iEYEARECAAYFAknjqdYACgkQE5f5cImnZruhawCgqqkl3NPljMkNRz8buEYROGUO > R2kAnRHhQmWJVtXq/j2wbNy64q6QWe+u > =3DOkiS > -----END PGP SIGNATURE----- > = From yiu_lee@cable.comcast.com Tue Apr 14 06:04:50 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952F73A67E6; Tue, 14 Apr 2009 06:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 sJAVbAzWcQvV; Tue, 14 Apr 2009 06:04:49 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id EF14D3A6A37; Tue, 14 Apr 2009 06:04:48 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.33953122; Tue, 14 Apr 2009 09:02:28 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 09:02:28 -0400 Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.76]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Apr 2009 13:02:13 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 14 Apr 2009 09:02:07 -0400 From: "Yiu L. Lee" To: Joe Touch , Magnus Westerlund Message-ID: Thread-Topic: [Softwires] [tcpm] TCP MSS clamping to try to deal with MTU issues in Dual-Stack Lite Thread-Index: Acm5iNT/rkjheLTqSaKKqnVN179ifQDeGHg8 In-Reply-To: <49DBD9AF.4040605@isi.edu> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 14 Apr 2009 13:02:28.0599 (UTC) FILETIME=[43BF3070:01C9BD01] X-Mailman-Approved-At: Tue, 14 Apr 2009 08:24:13 -0700 Cc: softwires@ietf.org, tcpm@ietf.org Subject: Re: [tcpm] [Softwires] TCP MSS clamping to try to deal with MTU issues in Dual-Stack Lite 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, 14 Apr 2009 13:04:50 -0000 HI Joe, In RFC2385 - Section 2.0 Item 2, it says 2. the TCP header, excluding options, and assuming a checksum of zero Since TCP options are excluded, changing MSS won't affect the MD5 mechanism= , will it? In draft-ietf-tpcm-tcp-auth-opt-04.txt - Section 5 Item 2, it says 2. A TCP option flag. When 0, this flag allows default operation, i.e., TCP options are included in the MAC calculation, with TCP- AO's MAC field zeroed out. When 1, all options (excluding TCP-AO) are excluded from all MAC calculations (skipped over, not simply zeroed). The option flag applies to TCP options in both directions (incoming and outgoing segments). >> The TCP option flag MUST NOT change during a TCP connection. The TCP option flag cannot change during a connection because TCP state is coordinated during connection establishment. TCP lacks a handshake for modifying that state after a connection has been established. Changing MSS could be a problem when TCP option flag is set to 0. When the flag is set to 1, changing MSS is fine, isn't it? Thanks, Yiu=20 =20 On 4/7/09 6:54 PM, "Joe Touch" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi, all, >=20 > The solution has a bug: if TCP traffic uses TCP MD5 or TCP-AO, then it > needs to be handled like non-TCP traffic, since MSS revision would > destroy the packet's integrity. >=20 > IMO, this should be handled the simple way - remove the TCP case, and > handle all traffic the non-TCP way. >=20 > Finally, if a NAT ever refuses to reassemble anything, it MUST issue an > ICMP too-big IMO. The whole idea of creating a problem (encapsulating, > decreasing the effective MSS on a path) then not cleaning it up > yourself, or deciding when to clean it up based on *current* assumptions > of network traffic is a bad idea and shouldn't be supported. >=20 > Joe >=20 > Magnus Westerlund wrote: >> Hi, >>=20 >> There is a proposal to use TCP MSS clamping to deal with MTU issues that >> comes from Dual-stack lite's tunnel encapsulation. >>=20 >> I think it would be good if TCPM could provide some feedback on this >> proposal. >>=20 >> The relevant document and section: >> http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-00 >>=20 >> 7.4. MTU >>=20 >>=20 >> Using an encapsulation (IP in IP or L2TP) to carry IPv4 traffic over >> IPv6 will reduce the effective MTU of the datagrams. Unfortunately, >> path MTU discovery is not a reliable method to deal with this. As >> such a combination of solutions is suggested: >>=20 >> o For TCP traffic, let the carrier-grade NAT rewrite the MSS in the >> first SYN packet to a lower value. >>=20 >> o For non-TCP traffic, perform fragmentation and reassembly over the >> tunnel between the home gateway and the carrier grade NAT. In >> practice, this means put the IPv4 packet into a large IPv6 packet >> and fragment/reassemble the IPv6 packet at each endpoint of the >> tunnel. There is a performance price to pay for this. >> Fragmentation is not very expensive, but reassembly can be, >> especially on the carrier-grade NAT that would have to keep track >> of a lot of flows. However, such a carrier-grade NAT would only >> have to perform reassembly for large UDP packets sourced by >> customers, not for large UDP packets received by customers. In >> other words, streaming video to a customer would not have a >> significant impact on the performance of the carrier-grade NAT, >> but will require more work on the home gateway side. >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> IETF Transport Area Director & TSVWG Chair >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iEYEARECAAYFAknb2a8ACgkQE5f5cImnZrs0ewCg7ScElkpLrz20zSpTMnXuRApa > CPsAoIyhk9N9K2fPpEJTyShMKeZNLxD/ > =3D9ob2 > -----END PGP SIGNATURE----- > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 From joelja@bogus.com Tue Apr 14 07:56:35 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738513A68ED; Tue, 14 Apr 2009 07:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 y8cFYg57EBUF; Tue, 14 Apr 2009 07:56:34 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 3A3213A6B0D; Tue, 14 Apr 2009 07:56:34 -0700 (PDT) Received: from [172.168.1.113] (adsl-76-205-24-189.dsl.pltn13.sbcglobal.net [76.205.24.189]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n3EEvdsG047791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Apr 2009 14:57:41 GMT (envelope-from joelja@bogus.com) Message-ID: <49E4A45B.4040402@bogus.com> Date: Tue, 14 Apr 2009 07:57:31 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Lars Eggert References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9233/Tue Apr 14 09:45:01 2009 on nagasaki.bogus.com X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 14 Apr 2009 08:24:13 -0700 Cc: "Smith, Donald" , 'Joe Abley' , "'opsec@ietf.org'" , "'tcpm@ietf.org'" , Joe Touch Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 14 Apr 2009 14:56:35 -0000 IETF list omitted for brevity... I think this is exactly the kind of discussion that this document needed, and I glad that we've finally managed to stimulate it. In my own opinion: I do belive that implementation advice is in scope for the ietf. We should plow operational experience with our protocol stack and it's limitations back into the standards process, We should avoid producing advice on general cases that would result in protocols becoming more rather than less brittle except when absolutely necessary. We should be mindful that existing deployed implementations are unlikely to change based solely on recommendations. joel Lars Eggert wrote: > Hi, > > > > On 2009-4-14, at 1:38, Joe Touch wrote: >>>> Advice in making a hardened version of TCP would be useful to the >>>> implementation community. >>> >>> To a large extent this is what draft-gont-tcp-security is about. >> >> Implementation advice is outside the scope of the IETF. It's not even >> operational, IMO. > > I do believe there is value in having a document that would inform a > stack vendor of various potential attack vectors against a TCP stack and > what techniques exist to harden their stacks. > > I agree with Joe that some of the hardening techniques that vendors are > implementing come with consequences (make TCP more brittle). To me, this > is a *reason* this document should be published via the IETF (i.e., > TCPM) - we are probably in the best position to correctly evaluate and > classify the impact of various hardening techniques. Stack vendors have > been putting these mechanisms in to their stacks without clear > specifications and discussions of the potential upsides and downsides > that would let them make an educated decision. It seems clear to me that > the vendor community is looking for guidance here, and I do believe the > IETF should give it. > > Yes, there is a fine line here, where some of the hardening techniques > introduce some new assumptions on what the segment flow of a valid > connection looks like, etc. It will be important to accurately describe > the downsides of some of these techniques, especially where they could > result in valid connections being dropped. > > Lars > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From Donald.Smith@qwest.com Tue Apr 14 08:19:45 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389C83A6AF6; Tue, 14 Apr 2009 08:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6WNdKv7LTdz; Tue, 14 Apr 2009 08:19:44 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id F40CB3A69FF; Tue, 14 Apr 2009 08:19:43 -0700 (PDT) Received: from sudnp796.qintra.com (sudnp796.qintra.com [151.116.2.212]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id n3EFKnFX018059; Tue, 14 Apr 2009 09:20:49 -0600 (MDT) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.0/8.14.0) with ESMTP id n3EFKf6W005198; Tue, 14 Apr 2009 09:20:42 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Tue, 14 Apr 2009 09:20:42 -0600 From: "Smith, Donald" To: "'Joe Touch'" , "'Fernando Gont'" Date: Tue, 14 Apr 2009 09:20:41 -0600 Thread-Topic: [OPSEC] [tcpm] draft-gont-tcp-security Thread-Index: Acm811oKZ1TOpUQ2Qjei9FPovceZAgAOO5Bg Message-ID: References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A856.9020703@isi.edu> In-Reply-To: <49E3A856.9020703@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 14 Apr 2009 08:24:13 -0700 Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 14 Apr 2009 15:19:45 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org]=20 > On Behalf Of Joe Touch > Sent: Monday, April 13, 2009 3:02 PM > To: Fernando Gont > Cc: tcpm@ietf.org; ietf@ietf.org; Joe Abley; opsec@ietf.org;=20 > Lars Eggert; Eddy,Wesley M. (GRC-RCN0)[Verizon] > Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >=20 > Fernando Gont wrote: > > Joe Touch wrote: > >=20 > >>> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a > >>> trivial attack in 2008 (Outpost24/CERT-FI), and we'll=20 > probably continue > >>> in this line, because we do nothing about it. > >> Whether we have this document or not, we will continue to=20 > have people > >> who incorrectly assume that TCP is secure. > >=20 > > That's correct. But we also have people that do know it is=20 > not mean to > > be secure, but that it should be resilient enough so that it's still > > usable. One way or another, most stacks implement=20 > counter-measures for > > SYN-floods (on which tcpm did publish something), timers on the > > FIN-WAIT-2 state, port randomization (on which tsvwg is=20 > working), ICP > > ISN randomization, etc. > >=20 > > The reason for which they did that was to improve TCP's=20 > security/resiliency. > >=20 > > Would you argue in favour of predictable ISNs, predictable ports, > > time-less FIN-WAIT-2 state, etc.? -- I hope you wouldn't. >=20 > These measures can be used to reduce the impact of attacks when TCP is > not secured. However, they DO NOT make TCP secure. They DO=20 > make TCP more > brittle - they limit the way in which two legitimate endpoints can do > legitimate things. >=20 > >>>> It summarizes issues already raised by the WG,=20 > >>> I believe this statement is unfair with respect to our=20 > document. e.g., > >>> has the issues described in Section 4.3, Section 9.2, or=20 > Section 10 been > >>> brought to tcpm before??? > >> I didn't say that's all it does ;-) Agreed that it raises=20 > other issues, > >> many of which are operational. > >=20 > > Many of which arise if you expect to use TCP in some other=20 > scenario that > > just two computers in a LAN. If that makes those issues=20 > "operational", I > > agree. >=20 > Many of those don't arise for computers in a wide area, or=20 > with millions > of other computers on the network either. They arise only=20 > when there are > active attacks, and only for some kinds of attackers=20 > (on-path, off-path, > high-speed access, etc.) >=20 > IMO, any decision which would be enabled or disabled depending on > whether security was a concern or performance was needed is=20 > operational. > E.g., port randomization helps only when attackers are=20 > off-path and when > port use is a fraction of the active port space. That's operational. > Ditto for ISN randomization. Given that this is opsec and that my major concern is the network elements= =20 I am much more concerned about "off-path" or "blind attacks" then direct at= tacks. Customers generally don't attack the router they are connected to. Peers generally don't attack the router they are connected to. >=20 > I.e., if the protection is not needed in the absence of=20 > attacks, it may > be operational. >=20 > >>>> TCP itself is not a secure protocol, nor is it intended to be. > >>> Yeah. But that does not mean that we should not do our=20 > best to improve > >>> it. > >> It means we should not try to give the incorrect impression that it > >> *can* be secured.=20 > >=20 > > It's security/resiliency can be improved. After all, if=20 > that were not > > the case, I guess you're wasting your time with TCP-AO. Or=20 > is it that > > you believe the only way to improve a protocol is to throw=20 > crypto at it? >=20 > I *know* that the only way to secure a protocol is to throw=20 > crypto at it. Now I think I understand what you mean by secure. I don't agree with your opinion. For example SSL is a form of encryption bu= t has done little to secure http as sites have trained customers to ignore cert errors. Banks put lock bitmaps on their pages to show how "safe" they are. Phishers depend on this user confusion! >=20 > I also *know* that unexpected packets are *not* indications=20 > of attacks. In the router world packets destined towards my routers that are "unexpecte= d" are often an indication of attack or a misconfigured system either can cause problems= for the network and blocking it TOWARDS the router is a BCP. >=20 > These two things are not evident in this document, and should be. > Further, this document should make a case as to whether the=20 > improvements > are operational or not. AFAICT, most are operational. >=20 > >> Interpreting every unexpected event as an attack makes > >> a protocol robust but also brittle; TCP is intended to=20 > trade flexibility > >> for security, AFAICT, because it is agnostic about intent,=20 > and gives the > >> benefit of doubt at all times.=20 > >=20 > > I would prefer that instead of making this type of broad=20 > statement, you > > would argue against a particular recommendation in > > draft-gont-tcp-security, and explain how it makes TCP more brittle. >=20 > Randomizing ports and ISNs assumes there is a window over which some > values are NOT used; that window precludes legitimate exchanges from > occurring. That is what I mean by "brittle." >=20 > >> Consider packet drops. That can happen due to loss, non-malicious > >> corruption, or jamming, e.g. In the last case, it makes=20 > sense to blast > >> copies of packets in the hopes of getting something=20 > through, but that's > >> NOT what we assume. > >=20 > > Wasn't this very behavior what lead to the Internet=20 > congestion collapse > > in the 80's, or am I missing something? >=20 > Loss of a segment can mean: > a) congestion (correlated drops) > b) non-correlated drops (not related to increasing traffic) > c) active removal (attack) >=20 > If (a), then you backoff. That's how congestion collapse was=20 > addressed. >=20 > If you believe that packet drops are caused by either non-correlated > drops or active removal, you send MORE - you send copies of=20 > each packet, > e.g. That is NOT what we assume, but what I presume you ought to > recommend in a document that assumes that every event that COULD have > been an attack probably is an attack. >=20 > >>> Please talk to vendors. I don't want to reproduce here=20 > what seems to > >>> be the consensus among vendors with respect to the=20 > current state of > >>> affairs in terms of how up-to-date our specs are. > >> Vendors misapply our protocols then complain that they=20 > don't work. Yes, > >> there are operational issues, but one severe operational=20 > issue is not > >> using security for some policy, financial, or operation=20 > expense and then > >> complaining that nonsecure TCP is being attacked. > >=20 > > Joe, we're talkng about a simple web server being taken=20 > down because of > > a SYN flood, a FIN-WAIT-2 flood, or the like. Even the most=20 > stupid web > > server should survive these types of attacks. >=20 > If you're talking about implementation advice (don't put all your > resources in pending connections), I agree that a good implementation > should be implemented well. But that's operational / implementation > advice, not protocol advice. >=20 > I do not agree that all web servers should implement SYN cookies, e.g. >=20 > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iEYEARECAAYFAknjqFYACgkQE5f5cImnZrtBNwCgiJPsTDBt34Im+s/TFkBm90DE > Xn4AoNlUvCAucvZoVVMTpex4sMXAaXb2 > =3D1ijT > -----END PGP SIGNATURE----- > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > = From touch@ISI.EDU Tue Apr 14 08:29:36 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9792C3A6DCC; Tue, 14 Apr 2009 08:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 kL2CS0Qy0X3I; Tue, 14 Apr 2009 08:29:35 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B6B753A6DE3; Tue, 14 Apr 2009 08:29:35 -0700 (PDT) Received: from [192.168.1.44] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3EFUAtR011014; Tue, 14 Apr 2009 08:30:12 -0700 (PDT) Message-ID: <49E4AC01.5060104@isi.edu> Date: Tue, 14 Apr 2009 08:30:09 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Smith, Donald" References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A856.9020703@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Fernando Gont' Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 14 Apr 2009 15:29:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Inline... > Given that this is opsec and that my major concern is the network elements > I am much more concerned about "off-path" or "blind attacks" then direct attacks. > Customers generally don't attack the router they are connected to. > Peers generally don't attack the router they are connected to. Some routers are on shared-access media. Other routers are connected across unsecured network elements - e.g., to network management components, etc. On-path doesn't mean directly connected on one hop - it includes the entire path. ... >> > I *know* that the only way to secure a protocol is to throw >> > crypto at it. > > Now I think I understand what you mean by secure. > I don't agree with your opinion. For example SSL is a form of encryption > but has done little to > secure http as sites have trained customers to ignore cert errors. > Banks put lock bitmaps on their pages to show how "safe" they are. > Phishers depend on this user confusion! Mechanism cannot compensate for users that ignore it. >> > I also *know* that unexpected packets are *not* indications >> > of attacks. > > In the router world packets destined towards my routers that are > "unexpected" are often an indication of attack or a misconfigured > system either can cause problems for the network and blocking it > TOWARDS the router is a BCP. I'm talking about expectations within a TCP connection, or about the establishment of TCP connections. This doc addresses TCP, not the Internet in general. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknkrAEACgkQE5f5cImnZrvCuwCgmNXYuIsIz0D3sKZPGPS4s9I/ a4UAn1Y61FP4a45kZdAtGelzTp4ah51O =Z6sO -----END PGP SIGNATURE----- From wesley.m.eddy@nasa.gov Tue Apr 14 08:44:27 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2718A3A6E33 for ; Tue, 14 Apr 2009 08:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.405 X-Spam-Level: X-Spam-Status: No, score=-6.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 YKepyoxXwyaR for ; Tue, 14 Apr 2009 08:44:26 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 6A41E3A6936 for ; Tue, 14 Apr 2009 08:44:26 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id B589078433; Tue, 14 Apr 2009 10:45:37 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01.ndc.nasa.gov [198.117.4.160] (may be forged)) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n3EFjdse001946; Tue, 14 Apr 2009 10:45:39 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.4.160]) with mapi; Tue, 14 Apr 2009 10:45:37 -0500 From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" To: "tcpm@ietf.org" Date: Tue, 14 Apr 2009 10:45:37 -0500 Thread-Topic: WGLC on draft-ietf Thread-Index: Acm9GA415Wd77/J2SpqUcp662SX2dQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-04-14_07:2009-04-13, 2009-04-14, 2009-04-14 signatures=0 Cc: "k.avrachenkov@sophia.inria.fr" , Josh Blanton , "mallman@icir.org" Subject: [tcpm] WGLC on draft-ietf 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, 14 Apr 2009 15:44:27 -0000 We'd like to start a 2-week TCPM working group last call on the early retransmit draft: http://tools.ietf.org/html/draft-ietf-tcpm-early-rexmt-01 I don't think the document itself says it, but our charter has this for an Experimental target. WGLC comments would be appreciated by April 30. The document has been cooking for a long time in TSVWG before TCPM took it, and the authors think it's pretty mature based on the progress on it there and in TCPM since it was taken up by TCPM at IETF 69. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From wesley.m.eddy@nasa.gov Tue Apr 14 10:45:56 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B90D3A6E90 for ; Tue, 14 Apr 2009 10:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 CQ86JKbvsO5b for ; Tue, 14 Apr 2009 10:45:55 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id B59933A6EA1 for ; Tue, 14 Apr 2009 10:45:49 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 51BDF3282D3; Tue, 14 Apr 2009 12:47:01 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01.ndc.nasa.gov [198.117.4.160] (may be forged)) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n3EHl2Bl011851; Tue, 14 Apr 2009 12:47:03 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.4.160]) with mapi; Tue, 14 Apr 2009 12:47:00 -0500 From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" , "tcpm@ietf.org" Date: Tue, 14 Apr 2009 12:47:00 -0500 Thread-Topic: WGLC on draft-ietf-tcpm-early-rexmt Thread-Index: Acm9GA415Wd77/J2SpqUcp662SX2dQAELrEg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-04-14_08:2009-04-13, 2009-04-14, 2009-04-14 signatures=0 Cc: "k.avrachenkov@sophia.inria.fr" , Josh, Blanton , "mallman@icir.org" Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt 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, 14 Apr 2009 17:45:56 -0000 Just demonstrating my incompetence to use email ... the subject line on this should have included the draft name: draft-ietf-tcpm-early-rexmt so that it can be more easily located in searches, archives, etc ... sorry for the extra traffic to correct the subject line. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Eddy, Wesley M. (GRC-RCN0)[Verizon] >Sent: Tuesday, April 14, 2009 11:46 AM >To: tcpm@ietf.org >Cc: k.avrachenkov@sophia.inria.fr; Josh Blanton; mallman@icir.org >Subject: [tcpm] WGLC on draft-ietf > >We'd like to start a 2-week TCPM working group last call on the >early retransmit draft: >http://tools.ietf.org/html/draft-ietf-tcpm-early-rexmt-01 >I don't think the document itself says it, but our charter has >this for an Experimental target. > >WGLC comments would be appreciated by April 30. > >The document has been cooking for a long time in TSVWG before >TCPM took it, and the authors think it's pretty mature based >on the progress on it there and in TCPM since it was taken >up by TCPM at IETF 69. > >--------------------------- >Wes Eddy >Network & Systems Architect >Verizon FNS / NASA GRC >Office: (216) 433-6682 >--------------------------- > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From fernando.gont.netbook.win@gmail.com Tue Apr 14 11:12:40 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9AD3A6E31; Tue, 14 Apr 2009 11:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbLNVqmelL18; Tue, 14 Apr 2009 11:12:39 -0700 (PDT) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id 5E7293A6E1F; Tue, 14 Apr 2009 11:12:39 -0700 (PDT) Received: by gxk7 with SMTP id 7so573009gxk.13 for ; Tue, 14 Apr 2009 11:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=fV/JPQL733nZWB41/rMJagl/yIHeoNhAAEsSstTUcRk=; b=vAlZsIpuJ92c+2uV6RDgHKYqaIE4nPAOBPkm1PjRggkCOOOK9I6hoEuz0UmncvxJ/0 rxT/JTjB7e5bgeZLLmmJ+rm4MVVZx+kJ+/xaGsBU8m+t+x9lRRJxArwD88LIlFzem2UN RHEcPj612cB+JIQnRV8+D17Lg6cKCvZ7eyc28= 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=HFhJLFOxzkKttO3vbX4oCvfAagmujZWqKF3FIZnwiuKwMpzKqVTcww+yBS4Y/y2FuI /gFqVAfOObl7x3vedYElnIwDVJBzQHzvR3U8rq3hzqXts5mApJ5lIa0UYkI6Gcy8QkDn lMerUsqiXaRKD6FrRIgPCvX1uVcIR79LVuxCY= Received: by 10.100.45.9 with SMTP id s9mr10485951ans.133.1239732830709; Tue, 14 Apr 2009 11:13:50 -0700 (PDT) Received: from ?172.16.1.133? (host4.190-139-184.telecom.net.ar [190.139.184.4]) by mx.google.com with ESMTPS id 6sm531735yxg.30.2009.04.14.11.13.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Apr 2009 11:13:49 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E4D257.40504@gont.com.ar> Date: Tue, 14 Apr 2009 15:13:43 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Lars Eggert References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , Joe Touch , "Smith, Donald" , 'Joe Abley' , "'opsec@ietf.org'" Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 14 Apr 2009 18:12:40 -0000 Lars Eggert wrote: > I agree with Joe that some of the hardening techniques that vendors are > implementing come with consequences (make TCP more brittle). To me, this > is a *reason* this document should be published via the IETF (i.e., > TCPM) - we are probably in the best position to correctly evaluate and > classify the impact of various hardening techniques. Stack vendors have > been putting these mechanisms in to their stacks without clear > specifications and discussions of the potential upsides and downsides > that would let them make an educated decision. It seems clear to me that > the vendor community is looking for guidance here, and I do believe the > IETF should give it. This is the reason for which the output of the CPNI project was submitted as an IETF I-D. Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Tue Apr 14 11:34:54 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D93128C20E; Tue, 14 Apr 2009 11:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6NbMTWe0e8n; Tue, 14 Apr 2009 11:34:53 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.248]) by core3.amsl.com (Postfix) with ESMTP id 5E78E28C20F; Tue, 14 Apr 2009 11:34:52 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 23so1264150agd.12 for ; Tue, 14 Apr 2009 11:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=rVFU2xr2gLNcl2gqS0LzqIh7K8bb/pdodTsPZOr5SEI=; b=mH2q+Y8q5ugZLSo6BzKHZewGZICWKcJ8dSTfPUPnL7J92xhsSkLccQzsQXldVLmdXM bAJt+y2qMr740wcqDCJ5sWmobSx8YnGXrqEXPKU6/Mm9P7o86BNmwWR5xwN7xrArWH25 HrcTyaWnVLjPv2z9zsTnFrkFTr1rymSMAZGb4= 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=LP4Bdea5rmw+1Ne2gmCDzn9/+ycokHKL/BPnyX3XD/BQ2lQlefgl111B8fE0NJYTgR xl/I5WeSiP1A/FTEPI+FJArBUD7+MCY4mdzn8j2C8uhtPWjoqFVSCnvHQTGwOOZw5K5J wqjA6RxMrt0FFqTfTNZ5gC9hZfdTnNyLSb8IA= Received: by 10.90.88.16 with SMTP id l16mr10101126agb.112.1239734163524; Tue, 14 Apr 2009 11:36:03 -0700 (PDT) Received: from ?172.16.1.133? (host101.190-139-184.telecom.net.ar [190.139.184.101]) by mx.google.com with ESMTPS id 6sm264661agb.10.2009.04.14.11.36.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Apr 2009 11:36:02 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E4D78D.20004@gont.com.ar> Date: Tue, 14 Apr 2009 15:35:57 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Joel Jaeggli References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <49E4A45B.4040402@bogus.com> In-Reply-To: <49E4A45B.4040402@bogus.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Joe Abley' , "'opsec@ietf.org'" , "'tcpm@ietf.org'" , Joe Touch Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 14 Apr 2009 18:34:54 -0000 Hello, Joel, > I do belive that implementation advice is in scope for the ietf. > > We should plow operational experience with our protocol stack and it's > limitations back into the standards process, > > We should avoid producing advice on general cases that would result in > protocols becoming more rather than less brittle except when absolutely > necessary. > > We should be mindful that existing deployed implementations are unlikely > to change based solely on recommendations. Do you have a possible action plan to pursue this effort? 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 iljitsch@muada.com Tue Apr 14 12:26:09 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41453A6EB6 for ; Tue, 14 Apr 2009 12:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.232 X-Spam-Level: X-Spam-Status: No, score=-5.232 tagged_above=-999 required=5 tests=[AWL=1.367, 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 bPeErJHlKzQ0 for ; Tue, 14 Apr 2009 12:26:08 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 885CA28C228 for ; Tue, 14 Apr 2009 12:26:05 -0700 (PDT) Received: from [192.168.0.196] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n3EJOwx4073260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 14 Apr 2009 21:25:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: tcpm@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 21:25:39 +0200 References: <5D63E0F4-2784-4C50-833E-3A2E499DF55A@muada.com> X-Mailer: Apple Mail (2.930.3) Subject: [tcpm] Rewriting MSS option for NAT64 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, 14 Apr 2009 19:26:09 -0000 Hi, In the BEHAVE wg we're working on NAT64, a way to make IPv6 clients talk to IPv4 servers through a translator. It's a lot like NAT-PT but with many of the issues better addressed. See: http://tools.ietf.org/html/draft-bagnulo-behave-nat64-03 I've been working on text about packet sizes and fragmentation (see the text at the end of the message for context), and Lars asked me to ask you guys' input on this part: > The TCP MSS option [RFC 793] is used during the three-way handshake > by the two hosts involved to inform each other about the maximum TCP > segment size (assuming IP and TCP headers without options) that the > host can receive. > In practice, the MSS option is often used to make TCP work in the > presence of broken path MTU discovery. > To avoid unnecessary path MTU discovery cycles, a NAT64 SHOULD > rewrite the MSS option in SYN packets to the minimum of the original > MSS option, the NAT64's MTU on the IPv6 side - 60 and the NAT64's > MTU on the IPv4 side - 40. This applies to SYNs in both the IPv4-to- > IPv6 direction and the IPv6-to-IPv4 direction. Since this is already very widely deployed in boxes that do stuff like PPPoE that reduces the MTU on access networks, I'm assuming there is no problem with this, especially since we're putting this into a translator that breaks authentication etc anyway. Iljitsch Packet sizes It's the job of the network layer to adapt to different maximum packet sizes as packets move through the network. There are three mechanisms that handle this: transport layer negotiations such as the TCP MSS option, path MTU discovery and fragmentation. The difference between the IPv4 and IPv6 header sizes requires some handling in a NAT64 translator, and there are complications because of the differences between how IPv4 and IPv6 handle fragmentation, as well as the issue of how to demultiplex fragmented IPv4 packets. There are two approaches to path MTU discovery and fragmentation when translating from IPv6 to IPv4: 1. Set DF to 0 in the translated packets. This avoids path MTU discovery issues but leads to significant numbers of fragments. 2. Set DF to 1 in the translated packets. This supports path MTU discovery on the IPv4 side so unnecessary fragments are avoided, but it doesn't address the issue that IPv6 hosts are not required to perform PMTUD when sending packets of 1280 bytes or smaller. The choice made in this document is to support option 1 for packets upto 1280 bytes, and option 2 for packets larger than 1280 bytes. A NAT64 translator MUST have an MTU of at least 1280 on all of its interfaces, both IPv4 and IPv6 interfaces. TCP MSS option The TCP MSS option [RFC 793] is used during the three-way handshake by the two hosts involved to inform each other about the maximum TCP segment size (assuming IP and TCP headers without options) that the host can receive. In practice, the MSS option is often used to make TCP work in the presence of broken path MTU discovery. To avoid unnecessary path MTU discovery cycles, a NAT64 SHOULD rewrite the MSS option in SYN packets to the minimum of the original MSS option, the NAT64's MTU on the IPv6 side - 60 and the NAT64's MTU on the IPv4 side - 40. This applies to SYNs in both the IPv4-to-IPv6 direction and the IPv6-to-IPv4 direction. Path MTU discovery The vast majority of both IPv4 and IPv6 hosts use path MTU discovery [RFC 1191] [RFC 1981]. With IPv4, PMTUD can be enabled on a per-packet basis by setting the DF bit to 1. With IPv6, there is no need for PMTUD for packets up to 1280 bytes because all IPv6 hosts are required to be able to receive 1280-byte packets without fragmentation. When sending larger packets, IPv6 hosts implicitly use PMTUD. IPv6-to-IPv4 If the NAT64 has the same MTUs on its IPv6 and IPv4 interfaces, it will never have to generate "packet too big" messages for incoming IPv6 packets because the translation from IPv6 to IPv4 reduces the packet size by 20 bytes, more if the IPv6 packet has extension headers that are removed during the translation, such as the fragment header. If the MTU on the IPv6 side is larger than 1280 bytes and more than 20 bytes smaller than the MTU on the IPv4 side, the NAT64 MUST generate the appropriate "packet too big" messages on the IPv6 side. To support PMTUD, for translated packets that are larger than 1260 bytes on the IPv4 side (1280 bytes IPv6 packets with 20 byte size reduction through the translation), the DF bit is set to 1 in the resulting IPv4 packet. IPv4 routers may generate "packet too big" messages indicating a supported MTU size smaller than 1280 bytes. In those cases, the IPv6 hosts will continue to send packets larger than what the IPv4 path MTU can support. To allow packets to be delivered successfully in this case, the DF bit is set to 0 in all translated packets smaller than or equal to 1260 bytes, to allow these packets to be fragmented in the IPv4 network. Note: it is highly recommended for IPv4 hosts running services that may be used by IPv6 clients through a NAT64 translator to use an MTU size of at least 1260 bytes and to properly generate "packet too big" messages. When a NAT64 translates "packet too big" messages from IPv6 to IPv4, it adjusts the advertised MTU to the minimum of the original advertised MTU + 20, the NAT64's MTU on the IPv6 side + 20 and the NAT64's MTU on the IPv4 side. IPv4-to-IPv6 Because it may be necessary to include a fragmentation header or other extension header, the NAT64 MUST be prepared to generate "packet too big" messages for packets with the DF bit set to 1 received from the IPv4 side, regardless of the MTU sizes on the IPv4 and IPv6 interfaces. If the packet is larger than can be transmitted on the IPv6 side after translation, the NAT64 returns a "packet too big" message indicating the maximum IPv4 packet size that would be supported using the same translation as the current packet. This can be calculated as IPv4-packet-size - (IPv6-packet-size - IPv6-total- length) + 20. When a NAT64 translates "packet too big" messages from IPv4 to IPv6, it adjusts the advertised MTU to the minimum of the original advertised MTU - 20, the NAT64's MTU on the IPv6 side and the NAT64's MTU on the IPv4 side - 20. However, if the advertised MTU in "packet too big" messages is smaller than 1260 bytes, the value put into the translated "packet too big" message is 1280. This makes sure that the IPv6 host will limit its packet sizes to 1280 bytes, so its packets are subsequently translated into IPv4 packets with DF set to 0. (This deviates from [RFC 2765].) Fragmentation Because NAT deviates from normal router behavior, the limitation that IPv6 packets or IPv4 packets with DF set to 1 are not fragmented by routers doesn't apply to a NAT64 translator. Where appropriate, these packets are fragmented after translation as described below. Demultiplexing Because NAT64 provides a stateful many-to-one (perhaps even many-to- many) translation, it is necessary to recognize which session a given packet belongs to. For this, the TCP or UDP port numbers must be known, but these only occur in the first fragment of a fragmented packet. There are two possible ways to deal with this: 1. Reassemble the packet before translating it. 2. Create translation state for the fragments belonging to the same packet so each packet can be translated. Strategy 2 is attractive in large installations because it requires less storage and processing. However, it may still be necessary to buffer fragments for some time, as the fragment containing the first part of the packet (and with that, the port numbers) may not be the first one to arrive. Note: based on the assumptions that hosts generate fragments in-order and that reordering must happen through parallel network links and that the path between these parallel links and a NAT64 supports speeds of at least 10 Mbps, there is a very high probability that two out-of- order fragments making up a packet will arrive at the NAT64 within 50 to 100 milliseconds. Further assuming that fragmented traffic makes up less than 10% of all traffic, this only requires a buffer of 6 to 12,500 fragments (50 ms at 10 Mbps to 100 ms at 10 Gbps). In some cases, especially in the IPv6-to-IPv4 direction, there may only be a single session matching the fragment's source and destination addresses and protocol number. In these cases, it would be possible to translate the fragments out-of-order. A NAT64 translator MAY do this for TCP, however, it MUST NOT translate UDP packets before the first fragment is available. The reason for this is that the fragment could be part of a packet setting up a new session. However, with TCP session establishment packets don't carry data, so it's extremely unlikely that they are fragmented. This is not the case with UDP, and in the IPv4-to-IPv6 direction, a UDP packet may have a zero checksum, which must be recalculated when translating to IPv6, for which the entire packet must be available. IPv6-to-IPv4 For all IPv4 packets that the NAT64 creates through translation, the translator generates an ID value. This applies to all packets, regardless of their size or the value of the DF field. A NAT64 translator MAY employ strategies to avoid reusing an ID value for a certain source, destination, protocol tuple as long as possible. If the IPv4 packets are fragments of an IPv6 packet, then state is created that makes it possible for all the fragments to have the same ID value on the IPv4 side. [RFC 2765] specifies copying the lower bits from the IPv6 ID field in a fragment header (if present) to the IPv4 ID field, but this runs the risk of two IPv6 hosts talking to the same IPv4 destination through the NAT64 using the same ID value. Otherwise, when translating IPv6 packets with a fragmentation header, the fragments are translated as per [RFC 2765]. IPv4-to-IPv6 Because packets coming in on the IPv4 side may be larger than 1280 bytes after translation, a NAT64 MUST implement PMTUD on the IPv6 side. In other words, it must react to "packet too big" messages for any IPv6 destination that it communicates with by limiting the size of the packets that it sends to the advertised maximum. In the case where, after translation from IPv4 to IPv6, a packet is larger than a destination's PMTU, the NAT64 returns a "packet too big" as outlined earlier in the case that the DF bit was set to 1 in the IPv4 packet. If the DF bit was set to 0, the translator first translates the IPv4 packet, and then fragments the resulting IPv6 packets using normal IPv6 fragmentation rules. The value in the ID field is generated locally by the NAT64. If the IPv4 packet was a fragment, state is created that allows the same ID value to be used for all IPv6 packets or fragments that are part of the same original IPv4 packet. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From lars.eggert@nokia.com Wed Apr 15 00:16:32 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDAB93A6BAB; Wed, 15 Apr 2009 00:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxbJlxzh3Nfm; Wed, 15 Apr 2009 00:16:32 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 293B03A6B98; Wed, 15 Apr 2009 00:16:30 -0700 (PDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3F7HJqk064106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2009 10:17:21 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Todd Glassey In-Reply-To: <49E4E233.9040609@earthlink.net> Content-Type: multipart/signed; boundary=Apple-Mail-69--520365169; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 10:17:19 +0300 References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 15 Apr 2009 10:17:22 +0300 (EEST) Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , Joe Touch , "Smith, Donald" , 'Joe Abley' , "'opsec@ietf.org'" , Fernando Gont Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 15 Apr 2009 07:16:33 -0000 --Apple-Mail-69--520365169 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, Todd, On 2009-4-14, at 22:21, Todd Glassey wrote: > Fernando Gont wrote: >> Lars Eggert wrote: >>> I agree with Joe that some of the hardening techniques that >>> vendors are >>> implementing come with consequences (make TCP more brittle). To >>> me, this >>> is a *reason* this document should be published via the IETF (i.e., >>> TCPM) - we are probably in the best position to correctly evaluate >>> and >>> classify the impact of various hardening techniques. Stack vendors >>> have >>> been putting these mechanisms in to their stacks without clear >>> specifications and discussions of the potential upsides and >>> downsides >>> that would let them make an educated decision. It seems clear to >>> me that >>> the vendor community is looking for guidance here, and I do >>> believe the >>> IETF should give it. >>> >> >> This is the reason for which the output of the CPNI project was >> submitted as an IETF I-D. >> > Yeah - so then this would be tested across all of the local TCP > implementations including the MS, AT&T *(i.e. Lachman Associates Inc) > and possibly Mentat's fast system? Nothing would be "tested", the IETF isn't in the business of auditing TCP stacks. What we're talking about is describing attack vectors, potential countermeasures and the the impact (downsides) those countermeasures might come with. Implementors will need to decide for themselves if and how to apply any of these techniques to their stacks. Lars --Apple-Mail-69--520365169 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MTUwNzE3MjBaMCMGCSqGSIb3DQEJBDEWBBSSn2e9WQWGdMA9 e22FMJ0HHudOYzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAV273PUT8G+6aJDYm5JLQl2CNgVT9UCd5/iib8786AoCnc9JEZfun kGgkluGmlydWO1iqs6gJhF18Qn0KUXZdaryFuic8z5Ig+A4GS+Q4wNnxZ/nIGMgw0kH8EyNhjzye o4C2XBnOqbgBqfx/VHMv00NSFW5undLqIfI7xXLyQlwnaRmQZz9hGXgBCg3/WRZa69F3IV7gcd4U 20+D6qLQqENDMirkP5cO0hdYAiH9gfzaf1yFnltno03JkNyPIWErFXd6/qcZ2gjhquuUc/1PUuVW ZmHFDCOmEuhvEbFWOSa+vmC3GYV3ZBN+MF7TkmkfmkBrdOpi7LjBpsOUJvmV6gAAAAAAAA== --Apple-Mail-69--520365169-- From tglassey@earthlink.net Tue Apr 14 12:22:37 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF05A28C1B9; Tue, 14 Apr 2009 12:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LIST=2.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 8FsyJ-vuMFak; Tue, 14 Apr 2009 12:22:37 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id D21FB28C1B5; Tue, 14 Apr 2009 12:22:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ELMvYCbh+jvv0ubaw5sa+uuFZtDbE65BIFf6OzXhtS2DTBhp08l5OANDhMZ8PUYj; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.104.134.74] (helo=[192.168.1.138]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LtoCm-0005aN-1E; Tue, 14 Apr 2009 15:22:00 -0400 Message-ID: <49E4E233.9040609@earthlink.net> Date: Tue, 14 Apr 2009 12:21:23 -0700 From: Todd Glassey User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fernando Gont References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <49E4D257.40504@gont.com.ar> In-Reply-To: <49E4D257.40504@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79bd0f68e3a5c852fb565124da4159354c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.104.134.74 X-Mailman-Approved-At: Wed, 15 Apr 2009 08:02:13 -0700 Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , Joe Touch , "Smith, Donald" , 'Joe Abley' , "'opsec@ietf.org'" Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 14 Apr 2009 19:22:37 -0000 Fernando Gont wrote: > Lars Eggert wrote: > > >> I agree with Joe that some of the hardening techniques that vendors are >> implementing come with consequences (make TCP more brittle). To me, this >> is a *reason* this document should be published via the IETF (i.e., >> TCPM) - we are probably in the best position to correctly evaluate and >> classify the impact of various hardening techniques. Stack vendors have >> been putting these mechanisms in to their stacks without clear >> specifications and discussions of the potential upsides and downsides >> that would let them make an educated decision. It seems clear to me that >> the vendor community is looking for guidance here, and I do believe the >> IETF should give it. >> > > This is the reason for which the output of the CPNI project was > submitted as an IETF I-D. > Yeah - so then this would be tested across all of the local TCP implementations including the MS, AT&T *(i.e. Lachman Associates Inc) and possibly Mentat's fast system? > Kind regards, > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.238 / Virus Database: 270.11.57/2059 - Release Date: 04/14/09 14:52:00 > > From tglassey@earthlink.net Wed Apr 15 07:46:11 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454E13A6A45; Wed, 15 Apr 2009 07:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 GAo8UGfzC3Uv; Wed, 15 Apr 2009 07:46:10 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 434BC3A6944; Wed, 15 Apr 2009 07:46:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Xt1YVas4lT3EYf+o5AS8UQ3T7JFElyyx97LzJ+949KiyIKCXdAWupFW3nKtG6uYA; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.100]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lu6OU-0001Oy-U2; Wed, 15 Apr 2009 10:47:19 -0400 Message-ID: <49E5F36D.7020808@earthlink.net> Date: Wed, 15 Apr 2009 07:47:09 -0700 From: Todd Glassey User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Lars Eggert References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79f67c55b1fa4594b85a5844cb47905a42350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 X-Mailman-Approved-At: Wed, 15 Apr 2009 08:02:13 -0700 Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , Joe Touch , "Smith, Donald" , 'Joe Abley' , "'opsec@ietf.org'" , Fernando Gont Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 15 Apr 2009 14:46:11 -0000 Lars Eggert wrote: > Hi, Todd, > > On 2009-4-14, at 22:21, Todd Glassey wrote: >> Fernando Gont wrote: >>> Lars Eggert wrote: >>>> I agree with Joe that some of the hardening techniques that vendors >>>> are >>>> implementing come with consequences (make TCP more brittle). To me, >>>> this >>>> is a *reason* this document should be published via the IETF (i.e., >>>> TCPM) - we are probably in the best position to correctly evaluate and >>>> classify the impact of various hardening techniques. Stack vendors >>>> have >>>> been putting these mechanisms in to their stacks without clear >>>> specifications and discussions of the potential upsides and downsides >>>> that would let them make an educated decision. It seems clear to me >>>> that >>>> the vendor community is looking for guidance here, and I do believe >>>> the >>>> IETF should give it. >>>> >>> >>> This is the reason for which the output of the CPNI project was >>> submitted as an IETF I-D. >>> >> Yeah - so then this would be tested across all of the local TCP >> implementations including the MS, AT&T *(i.e. Lachman Associates Inc) >> and possibly Mentat's fast system? > > Nothing would be "tested", the IETF isn't in the business of auditing > TCP stacks. Yo Lars Good-morning, let me respond. "Sure it is..." let me amplify - Don't the IETF standards processes "require the development of two or more independent implementations of any given protocol specification and the associated interoperability testing to document that the suite runs as advertised in the specification?" - I generally refer to that as IOT (Inter-Operability Testing). And for what its worth the IETF's mergence towards a leading edge standards process also reinforces the importance of that testing too by the way. By comparison, in trailing edge standards processes the IOT is accomplished in the various implementations which are done in the industry. In leading edge models where there is genesis happening the testing would have to be included in the implementation of any prototypes of the stack or system and its operations. This IMHO is the real issue with the worlds abuse of the IETF's processes - they seem to think that RFC's are standards and there are many here who use that to substantiate their technological advantage in their marketing, meaning that they derive financial value from misrepresenting this to the commercial community as well I think. The fix for that is to make RFC's unreliable for use as a protocol specification for anything other than a Standards Track effort as they should be - a Request For Comments rather than something the Trust's selling access to. Todd Glassey > What we're talking about is describing attack vectors, potential > countermeasures and the the impact (downsides) those countermeasures > might come with. Implementors will need to decide for themselves if > and how to apply any of these techniques to their stacks. Which would be filed as a Use Case Document as a set lf BCP's for a protocol stanadard. This by the way is where the real value of the IETF comes in - in also telling people how to and how not to use these protocols. Todd > > Lars From lars.eggert@nokia.com Wed Apr 15 08:13:23 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DDDB3A697A; Wed, 15 Apr 2009 08:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrCEKjYZpM46; Wed, 15 Apr 2009 08:13:22 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 848423A6944; Wed, 15 Apr 2009 08:13:21 -0700 (PDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3FFEDg4046102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2009 18:14:14 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Todd Glassey In-Reply-To: <49E5F36D.7020808@earthlink.net> Content-Type: multipart/signed; boundary=Apple-Mail-8--491751556; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 18:14:13 +0300 References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net> <49E5F36D.7020808@earthlink.net> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 15 Apr 2009 18:14:15 +0300 (EEST) Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , Joe Touch , "Smith, Donald" , 'Joe Abley' , "'opsec@ietf.org'" , Fernando Gont Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 15 Apr 2009 15:13:23 -0000 --Apple-Mail-8--491751556 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-4-15, at 17:47, Todd Glassey wrote: > Lars Eggert wrote: >> Nothing would be "tested", the IETF isn't in the business of auditing >> TCP stacks. > Yo Lars Good-morning, let me respond. "Sure it is..." let me amplify - > > Don't the IETF standards processes "require the development of two or > more independent implementations of any given protocol specification > and > the associated interoperability testing to document that the suite > runs > as advertised in the specification?" this is required when moving from Proposed Standard to Draft Standard. (Also, what RFC are you quoting in the previous paragraph?) This doesn't apply to the document we're discussing here, because: >> What we're talking about is describing attack vectors, potential >> countermeasures and the the impact (downsides) those countermeasures >> might come with. Implementors will need to decide for themselves if >> and how to apply any of these techniques to their stacks. > Which would be filed as a Use Case Document as a set lf BCP's for a > protocol stanadard. This by the way is where the real value of the > IETF > comes in - in also telling people how to and how not to use these > protocols. Yes, it is likely that whatever the outcome is, the document would be published as Informational or BCP. Lars --Apple-Mail-8--491751556 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MTUxNTE0MTNaMCMGCSqGSIb3DQEJBDEWBBSGaD9k6ujSBpmQ e+RjH2JSDdpY+jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAH+EqL9M8xqKnh08WeyMxaSPBL8hsiqCwqgXeJ2xNY/InodiwCZLS htAgqRqKFbG9gVTV1nPmNTiQR5JNsatELiftw5jzRY9jWlyoYG6UeDQD83HF+YL6apPpoVMEu4iB m/+bo/kwJ7/vJKjhQT1xlga+zu0ZXOnxE9srUhwbnoKIy0qZAJYFmwjPcndlkVx9EeI/HJHVaR3F dprkEUvvwxhxSXRM4n09Mf/7gfa7fljRTiHQpu6TNv24vCrRoJqVSLaLFXb8+lppu4CiBxE18YgO yRzMevjxfbPz91/Mgri4YtNr7kiFZajwe0QNR/yexXmITsWoIp4UUwzcyOaB+QAAAAAAAA== --Apple-Mail-8--491751556-- From lars.eggert@nokia.com Thu Apr 16 13:10:09 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9233A6C28 for ; Thu, 16 Apr 2009 13:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jK8hCpCzQ4N for ; Thu, 16 Apr 2009 13:10:08 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 964A13A689B for ; Thu, 16 Apr 2009 13:10:07 -0700 (PDT) Received: from [192.168.0.199] (cs95200.pp.htv.fi [212.90.95.200]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3GKBGVA071874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Apr 2009 23:11:17 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <29AE22C3-F03F-48A8-B335-A7C8E0265406@nokia.com> From: Lars Eggert To: tcpm@ietf.org In-Reply-To: <20090402150706.EC83D28C222@core3.amsl.com> Content-Type: multipart/signed; boundary=Apple-Mail-50--387533344; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 23:11:11 +0300 References: <20090402150706.EC83D28C222@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Thu, 16 Apr 2009 23:11:17 +0300 (EEST) Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard 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, 16 Apr 2009 20:10:09 -0000 --Apple-Mail-50--387533344 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, authors, the IETF last call has ended, and it looks like the few comments I've seen will require some text changes, so I'm placing this document in the Revised ID Needed state. Also: Has the discussion of the comments that Fernando made concluded? Lars On 2009-4-2, at 18:07, The IESG wrote: > The IESG has received a request from the TCP Maintenance and Minor > Extensions WG (tcpm) to consider the following document: > > - 'Improving TCP's Robustness to Blind In-Window Attacks ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2009-04-16. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-11.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11735&rfc_flag=0 > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/421/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-50--387533344 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MTYyMDExMTJaMCMGCSqGSIb3DQEJBDEWBBRP0eXrFfv6GjA+ vykyAeTLEwtR9jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAWkxpImbt+NTwNgogx4MKNlRu59mN5Ll1JR+uvKijmcWYwWugjn05 mWaX6GwTxmbTv/r4/UsjhGtO4sYlPURStuK8m5262VTA6aJdP1cIeD1UrSifyrtGU+/sTj4GZBP2 4tZS3Yd9QkQCk3AIeICuwpxTZbLPQuZK7GepPe8TFeQclPO0qCaD52vKVjHxJ3ev+b6zLMhjJ+C8 DwNUiIJMaOzC4VyRCTyuu6Mc7Jvoa9D8pEPxTwxoqM4SQ3x5KmW7iJPwSkntBLseI8V2OTmV/DV8 sRt4mA3csZgO9dM1JE7OJSJprlU/I2Yr/KmRk5u2w775nCcMPTDrbYyjFKTldwAAAAAAAA== --Apple-Mail-50--387533344-- From fernando.gont.netbook.win@gmail.com Thu Apr 16 22:13:26 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F8F228C0DB; Thu, 16 Apr 2009 22:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ZPUaDEXl9svd; Thu, 16 Apr 2009 22:13:25 -0700 (PDT) Received: from mail-bw0-f176.google.com (mail-bw0-f176.google.com [209.85.218.176]) by core3.amsl.com (Postfix) with ESMTP id 21ACB28C0E4; Thu, 16 Apr 2009 22:13:23 -0700 (PDT) Received: by bwz24 with SMTP id 24so418183bwz.13 for ; Thu, 16 Apr 2009 22:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=dAPZdPPFdRglbMs537zf22J020PHTQ4As1lXE10gzik=; b=jViARJthJbmQsOrpSOhLPiPTEXO0nnA3Y5QZNaWdy7818UUanYGJXgiztWPBEA5MB0 MWn0ik3dCPRYZ/ab5O9FLqmISfeTHnYndb9XY3yrun0InpZYuzx8dy0OMoQq4DQnAIV+ bLp+L1YfnW8+RxFHukFF8SIVBcbMhXgHK0qmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=sK5IymLyPU0xERPRmQKukOXUapNUKdohHpbXRamMdavtPnJDGPtvpg/Z7e1/a2Br32 9GvOmQoNldTKcXRDpT6jjvw5tP24u7zXqF6TGi+2HMddNV6F01eSqRRSQ9rIyWJmAu9D wQQMWB9lPtNKs008ExTSw7Gc9PZhmaCgUB9wI= MIME-Version: 1.0 Sender: fernando.gont.netbook.win@gmail.com Received: by 10.86.27.19 with SMTP id a19mr1752067fga.22.1239945276521; Thu, 16 Apr 2009 22:14:36 -0700 (PDT) In-Reply-To: <0C53DCFB700D144284A584F54711EC58070763E3@xmb-sjc-21c.amer.cisco.com> References: <20090402150706.EC83D28C222@core3.amsl.com> <49E3ADA4.1090402@gont.com.ar> <0C53DCFB700D144284A584F54711EC58070763E3@xmb-sjc-21c.amer.cisco.com> Date: Fri, 17 Apr 2009 04:14:36 -0100 X-Google-Sender-Auth: 8784ca969af83ca6 Message-ID: From: Fernando Gont To: "Anantha Ramaiah (ananth)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, ietf@ietf.org Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard 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, 17 Apr 2009 05:13:26 -0000 On Mon, Apr 13, 2009 at 10:23 PM, Anantha Ramaiah (ananth) wrote: > > * The document never mentions the fact that this document is > > IPR-encumbered. As far as I recall, much of the dicussion > > within tcpm with respect to the level of requirements of this > > document (MAY/SHOULD/MUST, etc.) had to do with this fact. I > > believe the document should include a warning mentioning that > > there's an IPR on the document, so that implementers can > > consider this point in their decision of whether to implement > > the described mechanisms or not. > > I am confused what to do since this is being brought up very late in the > game. That said, there are *many* drafts/RFC's that have IPR on them in > the whole of ietf. Do all them explicitly state the IPR link ? I'll > leave it to the collective wisdom of the group and the chairs to offer > guidance on this matter. I personally believe this should be noted in all RFCs on which there's a known IPR. However, Joel Halpern mentioned this is not current practice. If that's the case, I'd have no problem with leaving it "as is". (FWIW, if you look at our tcp-security document, we do recommend the implementation of the counter-measures you propose, but just note that there's an IPR, and that implementers should research how this would affect them). > > * The document discusses blind attacks, and to some extent > > assesses the difficulty in guessing the four-tuple that > > identifies a TCP connection. > > However, it does not even mention port randomization, which > > is probably the most simple and straightforward approach for > > mitigating blind attacks against TCP. This was raised by me > > Well, the point is that source port randomization is something external > like Ipsec and nothing specfic to TCP. TCP will work with or without src > port randomization. I disagree. Port numbers are a TCP mechanism. How you select them is a TCP policy. The fact that there's no mandatory policy for selecting the port numbers doesn't mean that they things like "port randomization" are external. > Now the scope of this document is to improve > robustness to TCP esp. in cases where the TCP connection is not > protected by other means like TCP MD5 or TCP AO etc., Now this point is > very clear in the document. That said I have no issues putting a > reference to the port randomization in the document. What I mean is that anybody that cares about this stuff (FWIW, I do) would also implement port randmization, ISN randomization, etc. One might argue that there's no use in enforcing the more strict validation checks in your document if the stack uses easily predictable (and global) ISNs, and easily predictable ports for the outgoing connections. > > and other quite a few times in the tcpm wg list, pre and post > > wglc, but this comment was never addressed. It's particularly > > curious that port randomization is not mentioned when tsvwg > > is working on it (draft-ietf-tsvwg-port-randomization). > > Yes, you did raise this issue last time, but I did defer it to the WG > and did not receive any response, so I simply left it at that. IIRC, both Joe and me had agreed on this one (yeah, we did :-) ). > > * Among the factors that determine how easy these attacks be > > exploited is the window size. This document should provide, > > at the very least, pointers with advice on what to do with > > the tcp window. While quickly skimming through RFC 4953, it > > It does mentions about the window size relationship, For example in the > beginning sections of the document we briefly mention the window size > and the # of packets that is required to generate a successful attack. What I mean is: you should not use windows that are larger than necessary. Using larger windows than necessary doesn't come for free (e.g., it increases the chances of an attacker of successfully performing these attacks). > > * Yet another factor is TCP ISN randomization. At the very > > least, this document could/should a pointer to RFC 1948. We > > do offer a lengthy discussion of this and other issues in > > draft-gont-tcp-security and > > http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf > > Why should it talk about ISN randomization since ISN randomization, is > somewhat orthogonal to the type of attack here, it is not even one of > the attack vector. If I can predict the ISN, I don't have to guess it. Therefore, it's easier to successfully perform the attack. > We could refer this, but the scope of the current document is about the > RST/SYN and Data attacks and mitigations, Since this document generally > refers RFC 4953 (which came after this document was written. BTW) I > think this should suffice, IMO. I believe you should say something about this. How you address this is a matter of choice. e.g., you could craft your own text (just mention that sequence numbers should be generated in such a way that are not easily guessable by an off-path attacker), reference RFC 1948, or reference the work with did in the tcp-security I-D. > > * The counter-measure of for the SYN-based reset attack may > > have missed a common heuristics for the handling of SYN > > segments. See pages 86 and > > 87 of the UK CPNI paper on TCP security. FWIW, we argue that > > the processing of SYN segments proposed in [Ramaiah et al, > > 2008] should apply only for connections in any of the > > synchronized states other than the TIME-WAIT state. > > We just followed RFC 793 as the base and the changes are made w.r.t > that. TIME-WAIT may be an exception but doesn't RFC 793 already has that > language correct? Well, the timestamps was published *after* RFC 793. So RFC imsply doesn't address this, because timestamps didn't exist at the time. > > * When it comes to TCP-based blind-connection reset attacks, > > there's a much more trivial -- yet not discussed before? -- > > alternative. See Section 11.1.3 and Section 11.1.4 in > > draft-gont-tcp-security and the CPNI paper > > (http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf). > > These variants should, at the very least, be mentioned and a > > pointer provided to them as, at least in theory, are much > > easier to exploit. > > Those sounds like some new proposals (security and precedence) different > stacks would have taken different measures to address this issue. > Anyways this is something new and hence needs more discussion and > evaluation. Has these ideas been submitted in a draft to TCPM? (your > recent BCP document tcp-security, covers it ?) Yes, the tcp-security I-D covers it. This stuff came as a surprise while assessing RFC 793. One would expect that these attacks don't work in practice--- but you never know. However, IETF-wise they do... therefore I think it should be mentioned as another potential connection-reset attack vector (*much* easier, as you don't even have to guess the sequence number) > > * When it comes to the data injection attack, Michael > > Zalewski sketched another attack vector which may be easier > > to exploit. We discuss it in Section 16.2 of > > draft-gont-tcp-security and the CPNI doc, along with advice. > > IMO, this vector should be mentioned, too. > > This again is an attack which relies on the IP functionality and not > TCP. This one I may grant. > > I'm also glad that this doc is getting close to publication. > > Five years working on a document is quite a lot of time! > > Agreed. Esp when it has been running in the internet with multiple > vendors supporting these mitigations. Agreed. 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 sallyfloyd@mac.com Mon Apr 20 09:56:12 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7950628C14C for ; Mon, 20 Apr 2009 09:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.773 X-Spam-Level: X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WI8Yj3JOxH7M for ; Mon, 20 Apr 2009 09:56:11 -0700 (PDT) Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by core3.amsl.com (Postfix) with ESMTP id 8F70D28C2C3 for ; Mon, 20 Apr 2009 09:56:00 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [10.0.0.111] ([64.241.37.140]) by asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KIE00HPKSF8UH70@asmtp013.mac.com> for tcpm@ietf.org; Mon, 20 Apr 2009 09:57:16 -0700 (PDT) Message-id: <0A9A995C-2639-4075-BA62-9549A8D80611@mac.com> From: Sally Floyd To: "Agarwal, Anil" In-reply-to: <0B0A20D0B3ECD742AA2514C8DDA3B065020BED58@VGAEXCH01.hq.corp.viasat.com> Date: Mon, 20 Apr 2009 09:57:08 -0700 References: <0B0A20D0B3ECD742AA2514C8DDA3B065020BED58@VGAEXCH01.hq.corp.viasat.com> X-Mailer: Apple Mail (2.930.3) Cc: Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , tcpm , Amit Mondal Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-ecnsyn (Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets) 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: Mon, 20 Apr 2009 16:56:12 -0000 Anil - > Here are a few comments and suggestions on draft-ietf-tcpm- > ecnsyn-08.txt. Many thanks. I will reply in more detail, and make the suggested changes, in a week or two, when I get back from my mother's in Virginia. (We are helping her get ready to move out of the house she has lived in since 1956, to a new place...) - Sally http://www.icir.org/floyd/ From mallman@icir.org Tue Apr 21 05:46:40 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E936928C19C for ; Tue, 21 Apr 2009 05:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[AWL=-1.124, BAYES_40=-0.185] 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 vxOWXaOjZB75 for ; Tue, 21 Apr 2009 05:46:40 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id A055A3A69C6 for ; Tue, 21 Apr 2009 05:46:35 -0700 (PDT) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n3LClpDD011135 for ; Tue, 21 Apr 2009 05:47:51 -0700 Received: from lawyers.icir.org (unknown [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 90713397375F for ; Tue, 21 Apr 2009 08:47:46 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 8AB70CF72B8 for ; Tue, 21 Apr 2009 08:47:45 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Fly By Night MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma49265-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 21 Apr 2009 08:47:45 -0400 Sender: mallman@icir.org Message-Id: <20090421124745.8AB70CF72B8@lawyers.icir.org> Subject: [tcpm] rev 05 of 2581bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 12:46:41 -0000 ----------ma49265-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- At long last we have submitted a revision of the 2581bis I-D. It needs manual intervention from the secratariet. So, it'll be a bit before it shows up in the usual places. But, until then it is at: http://www.icir.org/mallman/papers/draft-ietf-tcpm-rfc2581bis-05.txt We believe that at this point all the comments made during the WGLC have been addressed (which is different from being incorporated as we have previously distilled on the list). Please do let us know if there are further things we need to take care of. allman ----------ma49265-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkntwHEACgkQWyrrWs4yIs5wwwCeKiZ81vf5O7K96dbbID0lBnIu QqoAoISBhXBh/93jIHGMIdRtpRLFXaU5 =Cw4T -----END PGP SIGNATURE----- ----------ma49265-1-- From brian.e.carpenter@gmail.com Fri Apr 17 14:02:13 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051EE3A6931; Fri, 17 Apr 2009 14:02:13 -0700 (PDT) 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 D3MrkIhZcSbI; Fri, 17 Apr 2009 14:02:12 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id DA7493A683F; Fri, 17 Apr 2009 14:01:58 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id 11so727791tim.25 for ; Fri, 17 Apr 2009 14:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=7nRDlwYoLpo7QwVYp9YCSHamnh2n2yjmv3EiDul1u00=; b=JE2eSbkUgTor/ZknfHm1Jq7CFdOU+9EeMMGFFaldZxiQxN+Y2L6cPDVCdP/D0f6YwO ByBdZSWjp7B9bHKtW9FlRWXP98BY+zB3nToG0o/N18waX5PapORUt3XjawEOtzjyyFAu daR214Gh9cWbjV1uNCYkpAxATzrLPbInhfBug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=FrE+hu6i0hJ0fBYNaAdDMS4qdDk2/cX+ZVW2QaZ+jXpbgg0M/K1NWrqTV1dL/AAZiz Hl+DozI5Xg88n/3uBwG0vlFY0o6I+kijBhZyXtgadjiALAOTM1EuArlYS0ob9wIcGY0d 8uYhBhuhJWbRbdfrOMvlxJYOSoDXAv4XVCMGc= Received: by 10.110.50.19 with SMTP id x19mr3247093tix.42.1240002192267; Fri, 17 Apr 2009 14:03:12 -0700 (PDT) Received: from ?10.1.1.4? (118-93-162-236.dsl.dyn.ihug.co.nz [118.93.162.236]) by mx.google.com with ESMTPS id u12sm1225374tia.4.2009.04.17.14.03.08 (version=SSLv3 cipher=RC4-MD5); Fri, 17 Apr 2009 14:03:10 -0700 (PDT) Message-ID: <49E8EE86.3010600@gmail.com> Date: Sat, 18 Apr 2009 09:03:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <20090402150706.EC83D28C222@core3.amsl.com> <49E3ADA4.1090402@gont.com.ar> <0C53DCFB700D144284A584F54711EC58070763E3@xmb-sjc-21c.amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 22 Apr 2009 08:02:48 -0700 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , ietf@ietf.org Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard 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, 17 Apr 2009 21:02:13 -0000 On 2009-04-17 17:14, Fernando Gont wrote: > On Mon, Apr 13, 2009 at 10:23 PM, Anantha Ramaiah (ananth) > wrote: > >>> * The document never mentions the fact that this document is >>> IPR-encumbered. ... > I personally believe this should be noted in all RFCs on which there's > a known IPR. However, Joel Halpern mentioned this is not current > practice. If that's the case, I'd have no problem with leaving it "as > is". (FWIW, if you look at our tcp-security document, we do recommend > the implementation of the counter-measures you propose, but just note > that there's an IPR, and that implementers should research how this > would affect them). Personal belief doesn't come into it. It's strictly defined in a BCP. RFC3979 tells us the rules about this. Basically, the RFC Editor will do what is required: "4. Actions for Documents for which IPR Disclosure(s) Have Been Received (A) When any Intellectual Property Right is disclosed before publication as an RFC, with respect to any technology or specification, described in a Contribution in the manner set forth in Section 6 of this document, the RFC Editor shall ensure that the document include a note indicating the existence of such claimed Intellectual Property Rights in any RFC published from the Contribution. (See Section 5 below.)" [Section 5 defines the exact text to be included in such RFCs. I believe you can use in xml2rfc.] "11. No IPR Disclosures in IETF Documents IETF and RFC Editor Documents must not contain any mention of specific IPR. All specific IPR disclosures must be submitted as described in Section 6. Specific IPR disclosures must not be in the affected IETF and RFC Editor Documents because the reader could be misled. The inclusion of a particular IPR disclosure in a document could be interpreted to mean that the IETF, IESG, or RFC Editor has formed an opinion on the validity, enforceability, or applicability of the IPR. The reader could also be misled to think that the included IPR disclosures are the only IPR disclosures the IETF has received concerning the IETF document. Readers should always refer to the on-line web page to get a full list of IPR disclosures received by the IETF concerning any Contribution. (http://www.ietf.org/ipr/)" Brian From david.borman@windriver.com Fri Apr 24 16:13:11 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655BC3A696E for ; Fri, 24 Apr 2009 16:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 syFpP0R6Irq4 for ; Fri, 24 Apr 2009 16:13:10 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 9F7BA3A68B0 for ; Fri, 24 Apr 2009 16:13:10 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n3ONER2Y000120; Fri, 24 Apr 2009 16:14:27 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 16:14:26 -0700 Received: from [172.25.44.3] ([172.25.44.3]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 16:14:26 -0700 Message-Id: <6675BD71-AB6A-4EE8-8212-CF18D4D680C6@windriver.com> From: David Borman To: tcpm@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 24 Apr 2009 18:14:25 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Apr 2009 23:14:27.0064 (UTC) FILETIME=[69C9CF80:01C9C532] Cc: tcpm-chairs@tools.ietf.org, tsv-ads@tools.ietf.org Subject: [tcpm] DRAFT: tcpm minutes for IETF74 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, 24 Apr 2009 23:13:11 -0000 Hi, I've just posted *DRAFT* minutes for TCPM for IETF74. Many thanks to Gorry and Matt who were the note takers. The first day minutes are in pretty good shape, I'm still in the process of editing and expanding the notes from the second day, I'm only about 1/2 done with them. But the deadline for the initial minutes is in about 1 hour, so I put up what I have. You can find them at: http://www.ietf.org/proceedings/09mar/minutes/tcpm.txt Feel free to send me any corrections, for this first pass I'm looking for corrections and clarifications to content, as opposed to things like grammar and spelling, which I am still working on. I'm going to continue working on the minutes next week, there'll probably be a new version available by mid-week. -David Borman, TCPM WG co-chair From nishida@sfc.wide.ad.jp Mon Apr 27 00:34:19 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1033A69C4 for ; Mon, 27 Apr 2009 00:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.415 X-Spam-Level: * X-Spam-Status: No, score=1.415 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] 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 gdgGnvupFm3J for ; Mon, 27 Apr 2009 00:34:18 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 8EF2C3A685A for ; Mon, 27 Apr 2009 00:34:18 -0700 (PDT) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 605674D8C0; Mon, 27 Apr 2009 16:37:15 +0900 (JST) Date: Mon, 27 Apr 2009 16:35:34 +0900 (JST) Message-Id: <20090427.163534.196491176.nishida@sfc.wide.ad.jp> To: david.borman@windriver.com From: Yoshifumi Nishida In-Reply-To: <6675BD71-AB6A-4EE8-8212-CF18D4D680C6@windriver.com> References: <6675BD71-AB6A-4EE8-8212-CF18D4D680C6@windriver.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] DRAFT: tcpm minutes for IETF74 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, 27 Apr 2009 07:34:19 -0000 Hello David, Thanks for the effort. I would like to clarify one point in the log. -- ?: transmit new data 7. cong window is 1. under slow start thresh (is 3) so can perform slow start, no? nishida> IMO, no. but this is actually good point for discussion. In my understanding, we cannot perform slow start here since ACK6 indicates the end of fast recovery. However, rfc3782 is ambiguous about this point. I think we need to clarify this. -- BTW, I've prepared a preliminary I-D for this. If someone could give me feedbacks, I would be grateful very much. http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-00.txt Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: David Borman Subject: [tcpm] DRAFT: tcpm minutes for IETF74 Date: Fri, 24 Apr 2009 18:14:25 -0500 Message-ID: <6675BD71-AB6A-4EE8-8212-CF18D4D680C6@windriver.com> > Hi, > > I've just posted *DRAFT* minutes for TCPM for IETF74. Many thanks to > Gorry and Matt who were the note takers. The first day minutes are in > pretty good shape, I'm still in the process of editing and expanding > the notes from the second day, I'm only about 1/2 done with them. But > the deadline for the initial minutes is in about 1 hour, so I put up > what I have. You can find them at: > > http://www.ietf.org/proceedings/09mar/minutes/tcpm.txt > > Feel free to send me any corrections, for this first pass I'm looking > for corrections and clarifications to content, as opposed to things > like grammar and spelling, which I am still working on. I'm going to > continue working on the minutes next week, there'll probably be a new > version available by mid-week. > > -David Borman, TCPM WG co-chair > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From lars.eggert@nokia.com Mon Apr 27 13:21:44 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE943A700E; Mon, 27 Apr 2009 13:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 40fg2yiMcT38; Mon, 27 Apr 2009 13:21:43 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id E70D028C1B8; Mon, 27 Apr 2009 13:21:18 -0700 (PDT) Received: from lars-2.vzbi.com (lars-2.vzbi.com [166.58.67.119]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3RKMY2e081933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Apr 2009 23:22:35 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com> From: Lars Eggert To: tcpm@ietf.org, opsec@ietf.org In-Reply-To: <49EE1873.1090907@gont.com.ar> Content-Type: multipart/signed; boundary=Apple-Mail-32-563544112; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 16:22:28 -0400 References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net> <49E5F36D.7020808@earthlink.net> <49EE1873.1090907@gont.com.ar> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Mon, 27 Apr 2009 23:22:36 +0300 (EEST) Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security 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, 27 Apr 2009 20:21:44 -0000 --Apple-Mail-32-563544112 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit [Trimming the CC list to the relevant WGs.] Hi, On 2009-4-21, at 15:03, Fernando Gont wrote: > P.S.: Is there any specific proposal/advice to pursue this effort? > There's has been some talk about tcpm vs opsec, but so far it is not > clear to me how to proceed here. if the IETF decides to work on this, I believe TCPM would be the most appropriate group, given that that's where the TCP expertise is. I'm fully OK with doing this in cooperation with OPSEC, maybe via a joint WG last call or other means, if they desire this. One question: If the IETF decides to publish a document in this space, and if you decide to offer draft-gont-tcp-security as a starting point for this work, are the UK CNPI and you as the author OK with the IETF WG obtaining change control? The WG consensus process would likely lead to changes compared to the current version, probably even significant changes. Lars --Apple-Mail-32-563544112 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MjcyMDIyMjlaMCMGCSqGSIb3DQEJBDEWBBTqQZ0uIgBV4gOc vgOYQ3UG8wVdZjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAftK3hpcO/EGaRwtKzh3ajaOlg2rXapCEEVTbY9ygcWw5ZAf1hhfo aJK+otNsRlrVVim8SAJNXdafprb4V5SFdFHYv0ggwfphwHP/LvsDg1dTTE/iXZOJcBf+sa5eX9UW 6+41VFjgp2SXxzwbUZU9fN6bbTfNZbYkFXKbW98GiQlrz/09/lzI0HifyODkDnxFDyVoyeO8X+r3 VqP1gac8AGnASSHVV7SUoxTFXGHmUMSxoEN/GrLetB4HUn0i67dvFOSuiJh6HSAEbHP7eP3YWrVL YAJntj59mwWjdx3Sr9i1bcZ0uaIiPCg1QYgIXEFD+WdeKN/3ZZohGxpTIFDSOAAAAAAAAA== --Apple-Mail-32-563544112--