From tcpm-bounces@ietf.org Sun Jun 1 15:30:10 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782673A689B; Sun, 1 Jun 2008 15:30:10 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A2E3A6778 for ; Sun, 1 Jun 2008 15:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=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 2Xw9CNxd7-Gb for ; Sun, 1 Jun 2008 15:20:11 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by core3.amsl.com (Postfix) with ESMTP id 726E63A68DD for ; Sun, 1 Jun 2008 15:17:45 -0700 (PDT) Received: (qmail 57209 invoked from network); 1 Jun 2008 21:14:49 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Jun 2008 21:14:49 -0000 Message-ID: <48432005.2070201@freebsd.org> Date: Mon, 02 Jun 2008 00:17:41 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: tcpm@ietf.org Subject: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I'm reworking/refactoring/rewriting the FreeBSD TCP input path (in a separate perforce tree at the moment) and in that process I'm evaluating all assumptions and test them against a close reading of all relevant RFCs. While reading and applying draft-ietf-tcpm-tcpsecure-09.txt I've come across a couple of inconsistencies and issues that require further clarification: Section 3.2 Mitigation of Blind RST [Real world observation] Some implementations send the RST not on rcv_nxt but on rcv_nxt-1 or rcv_nxt+rcv_win. Thus we accept three small windows of rcv_nxt(+-1), last_ack_sent(+-1) and rcv_nxt+rcv_win(+-1). Of course the challenge ACK should have the same effect at the expense of another round trip. While these three (two in case of rcv_nxt == last_ack_sent) do increase the chances of a succesful attack (only every third seq# has to be probed plus the average hit rate is increased due to having two/three different places that match) real world behavior and interop should be considered and discussed. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev1.316 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev1.259 Section 4.2 Mitigation of Blind SYN [Possible inconsistency in text] The test in 4.2 eq. 1) is a little different. In RFC793 it is: RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND in tcpsecure it is described as one byte larger beyond the real window: RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND. This seems to be incorrectly transcribed. Section 5.2 Mitigation of Blind data injection attack [Clarification] Data that doesn't satisfy the new check in first paragraph MUST be discarded silently. Before RFC793 used to require an ACK to be sent back. This change is not sufficiently explained and lacks an obvious rationale. The second related issue is where this check should be placed relative to RFC793 ordering? Before the fifth check, last sentence (page 72) "If the ACK acks something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return." or right after it? This has implications on the response as tcpsecure requires to silently discard the segment. If it weren't for the silent discard the new tcpsecure check could simply replace/extend the fifth check from RFC793. Feedback appreciated. -- Andre andre@FreeBSD.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 2 12:15:55 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7CEB3A6D05; Mon, 2 Jun 2008 12:15:55 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C1C3A6D04; Mon, 2 Jun 2008 12:15:55 -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 uwm5xy8ZjhRy; Mon, 2 Jun 2008 12:15:54 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 35CEA3A6D0D; Mon, 2 Jun 2008 12:10:21 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m52JAHmi005779; Mon, 2 Jun 2008 22:10:20 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 22:10:19 +0300 Received: from lars.dhcp.nanog.merit.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 22:10:18 +0300 Message-Id: <6658003A-540D-4A44-8180-70F1D90B70C1@nokia.com> From: Lars Eggert To: tcpm Extensions WG Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 2 Jun 2008 15:10:15 -0400 X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 02 Jun 2008 19:10:19.0187 (UTC) FILETIME=[4C4EA830:01C8C4E4] X-Nokia-AV: Clean Cc: TSV Area Subject: [tcpm] looking for TCPM chairs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Lars Eggert List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi, after long years of exemplary service, Mark and Ted have decided to step down as our chairs for TCPM. The two have been chairing TCPM since its first WG meeting at IETF-59 in Seoul, Korea. Thank you very much for your service to the community! I'm currently looking for qualified folks to succeed Mark and Ted as TCPM chairs. Please drop me a line if you have the necessary cycles and travel support. There is _no_ requirement to have prior IETF chairing experience. Lars _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 2 17:42:14 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9343C3A6A84; Mon, 2 Jun 2008 17:42:14 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598633A682B for ; Mon, 2 Jun 2008 17:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=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 lVV4QX+Fpr8z for ; Mon, 2 Jun 2008 17:42:12 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B46603A6B07 for ; Mon, 2 Jun 2008 17:41:20 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-109-69.lsanca.dsl-w.verizon.net [71.106.109.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m530f5Jh026841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jun 2008 17:41:07 -0700 (PDT) Message-ID: <48449321.5000609@isi.edu> Date: Mon, 02 Jun 2008 17:41:05 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: tcpm@ietf.org References: <48432005.2070201@freebsd.org> In-Reply-To: <48432005.2070201@freebsd.org> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: multipart/mixed; boundary="===============1874893403==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1874893403== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCC071FECF8688F28E20FA8F1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCC071FECF8688F28E20FA8F1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, all, This is, IMO, a signal to review the recommendations in Section 1.1. I=20 was always concerned that these mitigations would be misinterpreted as=20 applying to hosts in general, which they do not. The document, IMO, is insufficient in indicating therein that: - with source port randomization, the mitigations are not needed (port randomization provides a 2^15 strength amplification), even presuming source IP addresses are known - if source IP addresses are not known, the mitigations are not needed - the mitigations may increase the time needed to respond to a legitimate RST, incurring extra RTTs or retransmissions vs. an unmodified system - the mitigations are not a substitute for network or transport authentication, either of which obviate the need for the mitigations (yes, this is noted in the security considerations, but it's buried w.r.t. applicability) - the mitigations protect only off-path attacks; on-path attacks, such as ISPs shutting connections down deliberately, are not prevented by this mitigation (yes, also noted in security considerations, but again worth noting in applicability, and worth adding the ISP example, IMO) It seems like these ought to be added, in light of the note below. Joe Andre Oppermann wrote: > I'm reworking/refactoring/rewriting the FreeBSD TCP input path (in a se= parate > perforce tree at the moment) and in that process I'm evaluating all ass= umptions > and test them against a close reading of all relevant RFCs. >=20 > While reading and applying draft-ietf-tcpm-tcpsecure-09.txt I've come a= cross a > couple of inconsistencies and issues that require further clarification= : >=20 > Section 3.2 Mitigation of Blind RST >=20 > [Real world observation] > Some implementations send the RST not on rcv_nxt but on rcv_nxt-1 or > rcv_nxt+rcv_win. Thus we accept three small windows of rcv_nxt(+-1),= > last_ack_sent(+-1) and rcv_nxt+rcv_win(+-1). >=20 > Of course the challenge ACK should have the same effect at the expens= e > of another round trip. While these three (two in case of rcv_nxt =3D= =3D last_ack_sent) > do increase the chances of a succesful attack (only every third seq# = has to > be probed plus the average hit rate is increased due to having two/th= ree > different places that match) real world behavior and interop should b= e > considered and discussed. >=20 > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev= 1.316 > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev= 1.259 >=20 >=20 > Section 4.2 Mitigation of Blind SYN >=20 > [Possible inconsistency in text] > The test in 4.2 eq. 1) is a little different. In RFC793 it is: >=20 > RCV.NXT =3D< SEG.SEQ < RCV.NXT+RCV.WND >=20 > in tcpsecure it is described as one byte larger beyond the real windo= w: >=20 > RCV.NXT <=3D SEG.SEQ <=3D RCV.NXT+RCV.WND. >=20 > This seems to be incorrectly transcribed. >=20 >=20 > Section 5.2 Mitigation of Blind data injection attack >=20 > [Clarification] > Data that doesn't satisfy the new check in first paragraph MUST be di= scarded > silently. Before RFC793 used to require an ACK to be sent back. This = change > is not sufficiently explained and lacks an obvious rationale. >=20 > The second related issue is where this check should be placed relativ= e to > RFC793 ordering? Before the fifth check, last sentence (page 72) "If= the ACK > acks something not yet sent (SEG.ACK > SND.NXT) then send an ACK, dro= p the > segment, and return." or right after it? This has implications on th= e response > as tcpsecure requires to silently discard the segment. If it weren't= for the > silent discard the new tcpsecure check could simply replace/extend th= e fifth > check from RFC793. >=20 >=20 > Feedback appreciated. >=20 --------------enigCC071FECF8688F28E20FA8F1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRJMhE5f5cImnZrsRAmnrAJwIZbqKJkIuyKkyjG1IQlRfAsMDSgCg3zoP iLWQ8+rZw0WlJh6xlJraUKU= =HFKp -----END PGP SIGNATURE----- --------------enigCC071FECF8688F28E20FA8F1-- --===============1874893403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1874893403==-- From tcpm-bounces@ietf.org Mon Jun 2 19:46:50 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ABD03A6817; Mon, 2 Jun 2008 19:46:50 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F913A6817 for ; Mon, 2 Jun 2008 19:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=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 R2G6uUPvWBlw for ; Mon, 2 Jun 2008 19:46:47 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AF1383A69CA for ; Mon, 2 Jun 2008 19:46:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,581,1204531200"; d="scan'208";a="107505941" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Jun 2008 19:46:46 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m532kkiI031263; Mon, 2 Jun 2008 19:46:46 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m532kkDh027404; Tue, 3 Jun 2008 02:46:46 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jun 2008 19:46:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Jun 2008 19:45:15 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5805449484@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <48432005.2070201@freebsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Q&C regarding tcpsecure-09 recommendations Thread-Index: AcjENxDkBaV5f7Z/RZCyVPUpd3XH9wA4xJxg References: <48432005.2070201@freebsd.org> From: "Anantha Ramaiah (ananth)" To: "Andre Oppermann" , X-OriginalArrivalTime: 03 Jun 2008 02:46:06.0752 (UTC) FILETIME=[F8B9EA00:01C8C523] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6382; t=1212461206; x=1213325206; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20Q&C=20regarding=20tcpsecure-09 =20recommendations |Sender:=20; bh=IyeMOrUQazenFOQyHm+fx5pcIz/xaDWPC75g4uKi+Eo=; b=2Wn6PzN5/2tBGR+26oUyDEdP7sfQ2tKkPiahQ17RlFpqFdQKRpw3G27lPj 1sZE27sFe/bxdEZ1QHMwaUHQpJ/WL1Iuix+uRPPkI0na9fki6bs4jjCIqJGn RRXCsRzUEr; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Andre, Pl see comments inline. > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Andre Oppermann > Sent: Sunday, June 01, 2008 3:18 PM > To: tcpm@ietf.org > Subject: [tcpm] Q&C regarding tcpsecure-09 recommendations > > I'm reworking/refactoring/rewriting the FreeBSD TCP input > path (in a separate perforce tree at the moment) and in that > process I'm evaluating all assumptions and test them against > a close reading of all relevant RFCs. Cool, thanks. > > While reading and applying draft-ietf-tcpm-tcpsecure-09.txt > I've come across a couple of inconsistencies and issues that > require further clarification: > > Section 3.2 Mitigation of Blind RST > > [Real world observation] > Some implementations send the RST not on rcv_nxt but on rcv_nxt-1 or > rcv_nxt+rcv_win. Thus we accept three small windows of > rcv_nxt(+-1), > last_ack_sent(+-1) and rcv_nxt+rcv_win(+-1). > > Of course the challenge ACK should have the same effect at > the expense > of another round trip. While these three (two in case of > rcv_nxt == last_ack_sent) > do increase the chances of a succesful attack (only every > third seq# has to > be probed plus the average hit rate is increased due to > having two/three > different places that match) real world behavior and > interop should be > considered and discussed. After you sent the challenge ACK, are you saying that implementations can still respond with the above values ? (rcvnxt -1 ) rcvnxt + rcvwin (+-1) etc., ? OR are you saying that the seq# of RST with rcvnxt - 1 should be accepted [Some implementations do this to accept the RST of the keepalive packet] FWIW, section 8 (middlebox considerations talks about some corner cases) Also the following table summarises (standard way) way to generate RST 's : * Generating a RST packet in response to an incoming packet. * According to TCP/IP Illustrated, Vol 2, page 994: * * +--------------+----------------------------------------------------+ * | | RST segment generated | * | +----------------+-----------------+-----------------| * | rcvd segment | seq# | ack.field | flags | * |===================================================================| * | Contains ACK | rcvd ack.field | 0 | TH_RST | * |--------------|----------------+-----------------+-----------------| * | ACK-less | 0 | rcvd seq# + len | TH_RST | TH_ACK | * +--------------|----------------+-----------------+-----------------+ * * The ACK flag should be set in all segments except when an initial SYN * is sent. So all RST packet will have 0 for ack number, without the ACK * flag, except when the RST is in response to an SYN packet. */ > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_inpu > t.c#rev1.316 > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_inpu > t.c#rev1.259 > > > Section 4.2 Mitigation of Blind SYN > > [Possible inconsistency in text] > The test in 4.2 eq. 1) is a little different. In RFC793 it is: > > RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND > > in tcpsecure it is described as one byte larger beyond the > real window: > > RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND. > > This seems to be incorrectly transcribed. Good catch, I'll change it. I thought I had removed it before. [I think I know the reason why this = got added, this is one of the corner cases which we have fixed it long back, I'll see if I can remember that and post it later, in any case I don't want to fix that in this draft.] > > > Section 5.2 Mitigation of Blind data injection attack > > [Clarification] > Data that doesn't satisfy the new check in first paragraph > MUST be discarded > silently. Before RFC793 used to require an ACK to be sent > back. This change > is not sufficiently explained and lacks an obvious rationale. Good question, 793 implicitly tells that the following ACK range is acceptable : In other words an ACK value is acceptable if it is ((SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT). Anything > SND.NXT above would solicit an ACK to be sent back, this is simply an ACK being sent for something that has not yet been actually sent. With this mitigation we are saying that the acceptability range becomes : ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). Since we haven't accepted this segment we drop this silently to distinguish with the above case. This is whole point. (old ACK versus an ACK ack'ing data that is unsent) FWIW, this is been implemented and tested in some of the stacks and I don't recall seeing any issues here. I agree that generating an ACK back is also fine and shouldn't pose any issues. I will think about this a bit more and will get back since my opinion is either way is fine. > > The second related issue is where this check should be > placed relative to > RFC793 ordering? Before the fifth check, last sentence > (page 72) "If the ACK > acks something not yet sent (SEG.ACK > SND.NXT) then send > an ACK, drop the > segment, and return." or right after it? This has Should be before that, this is what we have tested with. Although I can't think of on top of my head what would happen if we put after that... > implications on the response > as tcpsecure requires to silently discard the segment. If > it weren't for the > silent discard the new tcpsecure check could simply > replace/extend the fifth > check from RFC793. Agreed. I think it is just a matter of perference and I think both choices don't have any implications that I can see. > > > Feedback appreciated. Thanks, -Anantha > > -- > Andre > > andre@FreeBSD.org > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 2 20:08:58 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A19F3A6860; Mon, 2 Jun 2008 20:08:58 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DC8C3A683F for ; Mon, 2 Jun 2008 20:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 UrQJCymIFd62 for ; Mon, 2 Jun 2008 20:08:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9ADAC3A6836 for ; Mon, 2 Jun 2008 20:08:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,581,1204531200"; d="scan'208";a="107513094" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Jun 2008 20:08:58 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5338w28007891; Mon, 2 Jun 2008 20:08:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m5338v3q002969; Tue, 3 Jun 2008 03:08:57 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jun 2008 20:08:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Jun 2008 20:08:07 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5805449498@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <48449321.5000609@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Q&C regarding tcpsecure-09 recommendations Thread-Index: AcjFErgKSgprEZYvRGe2FlnLoUalpQAESj7g References: <48432005.2070201@freebsd.org> <48449321.5000609@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , X-OriginalArrivalTime: 03 Jun 2008 03:08:57.0772 (UTC) FILETIME=[29EAF6C0:01C8C527] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6343; t=1212462538; x=1213326538; 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]=20Q&C=20regarding=20tcpsecure-09 =20recommendations |Sender:=20; bh=W79gfs0tRPaK55FS1r4Z85DQR2Z4gWHm57PpeINFIDo=; b=hNQTgvA85y4HDh7FR+n88cPxES4LvgpbwOkGSBkZDXMzMpGAUmcnB8k4AS 7Cfie3TIxPWUXDkoBVDEVca0oNl8AnSto7lMHvwXmOXgJuX7m7PgFmOhqwo/ Yprk2cgYYH; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Joe Touch > Sent: Monday, June 02, 2008 5:41 PM > To: tcpm@ietf.org > Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations > > Hi, all, Others can comment, but wanted to offer my perspective as one of the document's authors. Pl find inline responses.. > > This is, IMO, a signal to review the recommendations in > Section 1.1. I was always concerned that these mitigations tcpsecure-09 has been reviewed and that includes the AS. There have been some general comments received which will be incorporated in the next revision. > would be misinterpreted as applying to hosts in general, > which they do not. Actually this is TCP document and hence these mitigations apply to any system that thinks it needs those. Also the definition between hosts and routers have diminished long ago. The AS is in place for the very reason you wanted it to be, i.e, these mitigations are generally useful for long lived sessions (SHOULD) than short lived (MAY) sessions. A TCP stack which caters to multitude of applications (short and long lived) may want to take the super set approach, IMO. It is purely an implementation decision. > > The document, IMO, is insufficient in indicating therein that: > > - with source port randomization, the mitigations are not needed > (port randomization provides a 2^15 strength amplification), > even presuming source IP addresses are known Source port randomization is one way of adding robustness and does not every situation. Also you can't assume everyone is doing src port randomization. Even then having these mitigations would make the attacks described in the document harder to accomplish. > > - if source IP addresses are not known, the mitigations are not > needed I think this is very obvious in the document. Right from the intro which talks about the attack vectors, and what is needed to accomplish the attack. > > - the mitigations may increase the time needed to respond to > a legitimate RST, incurring extra RTTs or retransmissions > vs. an unmodified system Yes, this is obvious too due to the challenge ACK being sent. > > - the mitigations are not a substitute for network or > transport authentication, either of which obviate the need > for the mitigations (yes, this is noted in the security > considerations, but it's buried w.r.t. applicability) Oh, the way I read the draft the above fact is mentioned all over the draft.. I can point out all the places if you want, but we have been thru this before and I have incorporated the feedback received from you but I am surprised that you are bringing this one up now. > > - the mitigations protect only off-path attacks; on-path > attacks, such as ISPs shutting connections down deliberately, > are not prevented by this mitigation (yes, also noted > in security considerations, but again worth noting in > applicability, and worth adding the ISP example, IMO) Well, I would think that we generally don't want to repeat the same text all over the document again and again, but if the work group believes in this redundancy as you semm to do, I am more than willing to add it. -Anantha > > It seems like these ought to be added, in light of the note below. > > Joe > > Andre Oppermann wrote: > > I'm reworking/refactoring/rewriting the FreeBSD TCP input > path (in a > > separate perforce tree at the moment) and in that process I'm > > evaluating all assumptions and test them against a close > reading of all relevant RFCs. > > > > While reading and applying draft-ietf-tcpm-tcpsecure-09.txt > I've come > > across a couple of inconsistencies and issues that require > further clarification: > > > > Section 3.2 Mitigation of Blind RST > > > > [Real world observation] > > Some implementations send the RST not on rcv_nxt but on > rcv_nxt-1 or > > rcv_nxt+rcv_win. Thus we accept three small windows of > rcv_nxt(+-1), > > last_ack_sent(+-1) and rcv_nxt+rcv_win(+-1). > > > > Of course the challenge ACK should have the same effect > at the expense > > of another round trip. While these three (two in case of > rcv_nxt == last_ack_sent) > > do increase the chances of a succesful attack (only every > third seq# has to > > be probed plus the average hit rate is increased due to > having two/three > > different places that match) real world behavior and > interop should be > > considered and discussed. > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_inpu > t.c#rev1.316 > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev1 > > .259 > > > > > > Section 4.2 Mitigation of Blind SYN > > > > [Possible inconsistency in text] > > The test in 4.2 eq. 1) is a little different. In RFC793 it is: > > > > RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND > > > > in tcpsecure it is described as one byte larger beyond > the real window: > > > > RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND. > > > > This seems to be incorrectly transcribed. > > > > > > Section 5.2 Mitigation of Blind data injection attack > > > > [Clarification] > > Data that doesn't satisfy the new check in first > paragraph MUST be discarded > > silently. Before RFC793 used to require an ACK to be sent > back. This change > > is not sufficiently explained and lacks an obvious rationale. > > > > The second related issue is where this check should be > placed relative to > > RFC793 ordering? Before the fifth check, last sentence > (page 72) "If the ACK > > acks something not yet sent (SEG.ACK > SND.NXT) then send > an ACK, drop the > > segment, and return." or right after it? This has > implications on the response > > as tcpsecure requires to silently discard the segment. > If it weren't for the > > silent discard the new tcpsecure check could simply > replace/extend the fifth > > check from RFC793. > > > > > > Feedback appreciated. > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 2 20:20:28 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520563A6AC8; Mon, 2 Jun 2008 20:20:28 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3298B3A6A33 for ; Mon, 2 Jun 2008 20:20:26 -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] 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 nAYquMvhXAQe for ; Mon, 2 Jun 2008 20:20:25 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 02E7C3A6B63 for ; Mon, 2 Jun 2008 20:18:23 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-109-69.lsanca.dsl-w.verizon.net [71.106.109.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m533IEgO007547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jun 2008 20:18:16 -0700 (PDT) Message-ID: <4844B7F5.9030800@isi.edu> Date: Mon, 02 Jun 2008 20:18:13 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <48432005.2070201@freebsd.org> <48449321.5000609@isi.edu> <0C53DCFB700D144284A584F54711EC5805449498@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5805449498@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: multipart/mixed; boundary="===============2057998244==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2057998244== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig47F9B14F91274288608AE676" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig47F9B14F91274288608AE676 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: =2E.. >> - with source port randomization, the mitigations are not needed >> (port randomization provides a 2^15 strength amplification), >> even presuming source IP addresses are known >=20 > Source port randomization is one way of adding robustness and does not > every situation. Also you can't assume everyone is doing src port > randomization.=20 No, you cannot. The responsibility for protecting the session then falls = to the side that initiates it (fair territory, IMO), rather than the=20 side that receives the RST (which is arbitrary). > Even then having these mitigations would make the attacks > described in the document harder to accomplish. Agreed that it makes the attacks still harder, but if they're already=20 hard enough, then the mitigations aren't needed. >> - if source IP addresses are not known, the mitigations are not >> needed >=20 > I think this is very obvious in the document. Right from the intro whic= h > talks about the attack vectors, and what is needed to accomplish the > attack.=20 >=20 >> - the mitigations may increase the time needed to respond to >> a legitimate RST, incurring extra RTTs or retransmissions >> vs. an unmodified system >=20 > Yes, this is obvious too due to the challenge ACK being sent. >=20 >> - the mitigations are not a substitute for network or >> transport authentication, either of which obviate the need >> for the mitigations (yes, this is noted in the security >> considerations, but it's buried w.r.t. applicability) >=20 > Oh, the way I read the draft the above fact is mentioned all over the > draft.. I can point out all the places if you want, but we have been > thru this before and I have incorporated the feedback received from you= > but I am surprised that you are bringing this one up now. I noted below why I am raising it now (the FreeBSD note). >> - the mitigations protect only off-path attacks; on-path >> attacks, such as ISPs shutting connections down deliberately, >> are not prevented by this mitigation (yes, also noted >> in security considerations, but again worth noting in >> applicability, and worth adding the ISP example, IMO) >=20 > Well, I would think that we generally don't want to repeat the same tex= t > all over the document again and again, but if the work group believes i= n > this redundancy as you semm to do, I am more than willing to add it.=20 I don't think it's huge; it is just a summary of - as you note -=20 information noted elsewhere. Joe --------------enig47F9B14F91274288608AE676 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRLf2E5f5cImnZrsRAn6EAJ9FesvdETKEbPECPtte/j4hJM1g4gCeMBz+ XRjAZOtpJdeCwdAMPniCRhI= =yvqV -----END PGP SIGNATURE----- --------------enig47F9B14F91274288608AE676-- --===============2057998244== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============2057998244==-- From tcpm-bounces@ietf.org Wed Jun 4 09:58:41 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854B428C1F5; Wed, 4 Jun 2008 09:58:41 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AB0328C1F6 for ; Wed, 4 Jun 2008 09:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 utztxEzRzqgy for ; Wed, 4 Jun 2008 09:58:39 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 1A92628C1EF for ; Wed, 4 Jun 2008 09:58:38 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m54GwH7g006890; Wed, 4 Jun 2008 19:58:38 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Jun 2008 19:58:06 +0300 Received: from lars.dhcp.nanog.merit.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Jun 2008 19:58:06 +0300 Message-Id: <00BC7F35-5CE5-4142-AF30-7EDDB70A29D5@nokia.com> From: Lars Eggert To: ext Joe Touch In-Reply-To: <48449321.5000609@isi.edu> Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 4 Jun 2008 12:58:02 -0400 References: <48432005.2070201@freebsd.org> <48449321.5000609@isi.edu> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 04 Jun 2008 16:58:06.0299 (UTC) FILETIME=[28C382B0:01C8C664] X-Nokia-AV: Clean Cc: tcpm@ietf.org Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi, On 2008-6-2, at 20:41, ext Joe Touch wrote: > This is, IMO, a signal to review the recommendations in Section 1.1. > I was always concerned that these mitigations would be > misinterpreted as applying to hosts in general, which they do not. do you think that a short paragraph in Section 1.1 that discusses the downsides of implementing the checks where not needed would be helpful? Currently the document says "The mitigations suggested in this draft SHOULD be implemented in devices where the TCP connections are most vulnerable to the attacks described in this document. (...) These mitigations MAY be implemented in other cases." I think you're saying that the last sentence may not be detailed enough to allow implementors to judge the tradeoffs? Lars (as an individual) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 4 13:43:50 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB02C3A6D1B; Wed, 4 Jun 2008 13:43:50 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB6073A6D1B for ; Wed, 4 Jun 2008 13:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=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 cnFDo9R5ZxqH for ; Wed, 4 Jun 2008 13:43:48 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by core3.amsl.com (Postfix) with ESMTP id 291713A6CFA for ; Wed, 4 Jun 2008 13:43:47 -0700 (PDT) Received: (qmail 228 invoked from network); 4 Jun 2008 19:40:23 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Jun 2008 19:40:23 -0000 Message-ID: <4846FE85.4050009@freebsd.org> Date: Wed, 04 Jun 2008 22:43:49 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: tcpm@ietf.org References: <48432005.2070201@freebsd.org> <48449321.5000609@isi.edu> In-Reply-To: <48449321.5000609@isi.edu> Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > Hi, all, > > This is, IMO, a signal to review the recommendations in Section 1.1. I > was always concerned that these mitigations would be misinterpreted as > applying to hosts in general, which they do not. I do not agree here. The recommendations in tcp-secure, IMHO, do apply to hosts in general and to servers in particular. Lets have a look at some examples: IRC Servers, Jabber Servers, Usenet/NNTP Servers, IMAP Servers, FTP Mirrors (rsync) as well as any other application that has long-lived and persistent connections. > The document, IMO, is insufficient in indicating therein that: > > - with source port randomization, the mitigations are not needed > (port randomization provides a 2^15 strength amplification), > even presuming source IP addresses are known Only few do port randomization over the full range. Most limit it to the high or low port range from which the applications draw. Lets consider some examples: Dest IP and port are pretty much a given. Source IP is probably known to an attacker (like in an IRC or Jabber network). That leaves the source port and seq#. Lets assume that the source port is in a fairly narrow range of a couple of thousand ports either on the low side 1024-5000 or in the high range of 49000-60000. Without full port randomization it is likely to be in the early port numbers. With a window of 64k (2^16) the attack space shrinks to 2^16/2 == 2^15 on average. That's 32k blind RST packets per source port. With larger windows, which become more common, even less. Sounds almost trivially doable. Seems to me a lot smarter to DDoS your favorite IRC network that way than through a traditional brute force traffic attack. The [RST mitigation] ideally, with only rcv_nxt, increases the attack space to 2^31. The three +-1 window approach to somewhere between 2^23 and 2^26. [SYN attack] of course is just as evil as RST attack and is completely solved by the challenge ACK (at the expense of potential bogus dupe-ack detection by the sender). [Slipping data] into the window is made way more difficult with the ACK check. Here we go from 2^15 chance at 64k window to 2^32. Very valuable I'd say. Coming back to the IRC server example an attacker can potentially take over a channel if he manages to insert the right command into a client-server or server-server stream. For the both the source IP and destination IP/port are known. To slip a malicious line I simply send a string terminating the previous line and add my line including line ending again. Then it doesn't really matter which part of the stream I hit. > - if source IP addresses are not known, the mitigations are not > needed For almost all examples above both endpoint plus at least one port number are known. > - the mitigations may increase the time needed to respond to > a legitimate RST, incurring extra RTTs or retransmissions > vs. an unmodified system Which isn't a terrible price to pay. As far as my understanding goes TCP is concerned with reliable transport of data, not absolutely reliable abortions of the same through RSTs and SYNs. They do play an important role in the functioning of the overall system but they are not sensitive to a delay of a couple of milliseconds. > - the mitigations are not a substitute for network or > transport authentication, either of which obviate the need > for the mitigations (yes, this is noted in the security > considerations, but it's buried w.r.t. applicability) There are some problems with transport authentication. IPSec does authentication validation before the segment is checked by the TCP layer. TCP-MD5 can do better by doing all incoming segment checks (seq#, ack#, window, timestamps) before doing the MD5 computation. Nonetheless both can be used for exquisite CPU exhaustion attacks. The better my filter is in the TCP-MD5 case, the less exposure a system has. Hence I argue that tcp-secure is actually helps TCP-MD5. > - the mitigations protect only off-path attacks; on-path > attacks, such as ISPs shutting connections down deliberately, > are not prevented by this mitigation (yes, also noted > in security considerations, but again worth noting in > applicability, and worth adding the ISP example, IMO) Of course. So far nobody implied that it may protect again on-path attacker. Explicitly stating it in the document may no hurt though. -- Andre > It seems like these ought to be added, in light of the note below. > > Joe > > Andre Oppermann wrote: >> I'm reworking/refactoring/rewriting the FreeBSD TCP input path (in a >> separate >> perforce tree at the moment) and in that process I'm evaluating all >> assumptions >> and test them against a close reading of all relevant RFCs. >> >> While reading and applying draft-ietf-tcpm-tcpsecure-09.txt I've come >> across a >> couple of inconsistencies and issues that require further clarification: >> >> Section 3.2 Mitigation of Blind RST >> >> [Real world observation] >> Some implementations send the RST not on rcv_nxt but on rcv_nxt-1 or >> rcv_nxt+rcv_win. Thus we accept three small windows of rcv_nxt(+-1), >> last_ack_sent(+-1) and rcv_nxt+rcv_win(+-1). >> >> Of course the challenge ACK should have the same effect at the expense >> of another round trip. While these three (two in case of rcv_nxt == >> last_ack_sent) >> do increase the chances of a succesful attack (only every third seq# >> has to >> be probed plus the average hit rate is increased due to having >> two/three >> different places that match) real world behavior and interop should be >> considered and discussed. >> >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev1.316 >> >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev1.259 >> >> >> >> Section 4.2 Mitigation of Blind SYN >> >> [Possible inconsistency in text] >> The test in 4.2 eq. 1) is a little different. In RFC793 it is: >> >> RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND >> >> in tcpsecure it is described as one byte larger beyond the real window: >> >> RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND. >> >> This seems to be incorrectly transcribed. >> >> >> Section 5.2 Mitigation of Blind data injection attack >> >> [Clarification] >> Data that doesn't satisfy the new check in first paragraph MUST be >> discarded >> silently. Before RFC793 used to require an ACK to be sent back. This >> change >> is not sufficiently explained and lacks an obvious rationale. >> >> The second related issue is where this check should be placed >> relative to >> RFC793 ordering? Before the fifth check, last sentence (page 72) >> "If the ACK >> acks something not yet sent (SEG.ACK > SND.NXT) then send an ACK, >> drop the >> segment, and return." or right after it? This has implications on >> the response >> as tcpsecure requires to silently discard the segment. If it >> weren't for the >> silent discard the new tcpsecure check could simply replace/extend >> the fifth >> check from RFC793. >> >> >> Feedback appreciated. >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 4 13:50:24 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF603A68AA; Wed, 4 Jun 2008 13:50:24 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B52113A6928 for ; Wed, 4 Jun 2008 13:50:23 -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 E9rzeO267AfH for ; Wed, 4 Jun 2008 13:50:22 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C8FBA3A68AA for ; Wed, 4 Jun 2008 13:50:22 -0700 (PDT) Received: from [127.0.0.1] (32.sub-70-213-140.myvzw.com [70.213.140.32]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m54Ko7nw006519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jun 2008 13:50:11 -0700 (PDT) Message-ID: <4846FFFF.9090309@isi.edu> Date: Wed, 04 Jun 2008 13:50:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Lars Eggert References: <48432005.2070201@freebsd.org> <48449321.5000609@isi.edu> <00BC7F35-5CE5-4142-AF30-7EDDB70A29D5@nokia.com> In-Reply-To: <00BC7F35-5CE5-4142-AF30-7EDDB70A29D5@nokia.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: multipart/mixed; boundary="===============0509839157==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0509839157== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA61292B78DAE0F9340FF1F96" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA61292B78DAE0F9340FF1F96 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > Hi, >=20 > On 2008-6-2, at 20:41, ext Joe Touch wrote: >> This is, IMO, a signal to review the recommendations in Section 1.1. I= =20 >> was always concerned that these mitigations would be misinterpreted as= =20 >> applying to hosts in general, which they do not. >=20 > do you think that a short paragraph in Section 1.1 that discusses the=20 > downsides of implementing the checks where not needed would be helpful?= Yes. > Currently the document says "The mitigations suggested in this draft=20 > SHOULD be implemented in devices where the TCP connections are most=20 > vulnerable to the attacks described in this document. (...) These=20 > mitigations MAY be implemented in other cases." I think you're saying=20 > that the last sentence may not be detailed enough to allow implementors= =20 > to judge the tradeoffs? Yes, that's partly it. The key is that there are two issues that don't=20 come out just because they're ref'd off to the document (i.e.,=20 "described in this document" isn't sufficient; it's important to=20 summarize these): 1. these mitigations help only a very small class of situations that may be typical for unprotected routers, but are currently very rare otherwise. 2. of particular recent note, these mitigations are not useful to on-path attacks, such as ISP-issued RSTs 2. adding these mitigations complicates the TCP implementation, and makes it less robust to legitimate RSTs, esp. in the presence of reordering; it can increase the time needed to reset a connection by one or more RTTs Joe --------------enigA61292B78DAE0F9340FF1F96 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRv//E5f5cImnZrsRAgNCAJ9LpfptlbZ7rmoTbZS75f4EXrLXGwCg382H CEyCrMloN3EYa5S/U/FGYtM= =LJib -----END PGP SIGNATURE----- --------------enigA61292B78DAE0F9340FF1F96-- --===============0509839157== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0509839157==-- From tcpm-bounces@ietf.org Wed Jun 4 14:13:36 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6961C3A6B3D; Wed, 4 Jun 2008 14:13:36 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62293A6849 for ; Wed, 4 Jun 2008 14:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=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 t1R3MqO42SRX for ; Wed, 4 Jun 2008 14:13:34 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by core3.amsl.com (Postfix) with ESMTP id E27F03A6B3D for ; Wed, 4 Jun 2008 14:13:33 -0700 (PDT) Received: (qmail 641 invoked from network); 4 Jun 2008 20:10:10 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Jun 2008 20:10:10 -0000 Message-ID: <48470580.1010408@freebsd.org> Date: Wed, 04 Jun 2008 23:13:36 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <48432005.2070201@freebsd.org> <0C53DCFB700D144284A584F54711EC5805449484@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5805449484@xmb-sjc-21c.amer.cisco.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Anantha Ramaiah (ananth) wrote: > Andre, > Pl see comments inline. Likewise. >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Andre Oppermann >> Sent: Sunday, June 01, 2008 3:18 PM >> To: tcpm@ietf.org >> Subject: [tcpm] Q&C regarding tcpsecure-09 recommendations >> >> I'm reworking/refactoring/rewriting the FreeBSD TCP input >> path (in a separate perforce tree at the moment) and in that >> process I'm evaluating all assumptions and test them against >> a close reading of all relevant RFCs. > > Cool, thanks. > >> While reading and applying draft-ietf-tcpm-tcpsecure-09.txt >> I've come across a couple of inconsistencies and issues that >> require further clarification: >> >> Section 3.2 Mitigation of Blind RST >> >> [Real world observation] >> Some implementations send the RST not on rcv_nxt but on rcv_nxt-1 or >> rcv_nxt+rcv_win. Thus we accept three small windows of >> rcv_nxt(+-1), >> last_ack_sent(+-1) and rcv_nxt+rcv_win(+-1). >> >> Of course the challenge ACK should have the same effect at >> the expense >> of another round trip. While these three (two in case of >> rcv_nxt == last_ack_sent) >> do increase the chances of a succesful attack (only every >> third seq# has to >> be probed plus the average hit rate is increased due to >> having two/three >> different places that match) real world behavior and >> interop should be >> considered and discussed. > > After you sent the challenge ACK, are you saying that implementations > can still respond with the above values ? (rcvnxt -1 ) rcvnxt + rcvwin > (+-1) etc., ? OR are you saying that the seq# of RST with rcvnxt - 1 > should be accepted [Some implementations do this to accept the RST of > the keepalive packet] This +-1 extension is done to accept the initial RST w/o having to send a challenge ACK. It has been observed by my fellow FreeBSD developer Qing Li that certain system send the RST to weird off-by-one places in either direction. A surprisingly large number of RSTs are generated by socket closes of connections that actually were in use shortly before. Depending on the exact timing of the connection teardown the RST is not sent in response to some incoming segment but from the tcpcb state to inform the other end of the immediate termination of this connection. > FWIW, section 8 (middlebox considerations talks about some corner cases) > > Also the following table summarises (standard way) way to generate RST > 's : > > * Generating a RST packet in response to an incoming packet. > * According to TCP/IP Illustrated, Vol 2, page 994: > * > * +--------------+----------------------------------------------------+ > * | | RST segment generated | > * | +----------------+-----------------+-----------------| > * | rcvd segment | seq# | ack.field | flags | > * |===================================================================| > * | Contains ACK | rcvd ack.field | 0 | TH_RST | > * |--------------|----------------+-----------------+-----------------| > * | ACK-less | 0 | rcvd seq# + len | TH_RST | TH_ACK | > * +--------------|----------------+-----------------+-----------------+ > * > * The ACK flag should be set in all segments except when an initial SYN > * is sent. So all RST packet will have 0 for ack number, without the > ACK > * flag, except when the RST is in response to an SYN packet. > */ > >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_inpu >> t.c#rev1.316 >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_inpu >> t.c#rev1.259 >> >> >> Section 4.2 Mitigation of Blind SYN >> >> [Possible inconsistency in text] >> The test in 4.2 eq. 1) is a little different. In RFC793 it is: >> >> RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND >> >> in tcpsecure it is described as one byte larger beyond the >> real window: >> >> RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND. >> >> This seems to be incorrectly transcribed. > > Good catch, I'll change it. I thought I had removed it before. > > [I think I know the reason why this = got added, this is one of the > corner cases which we have fixed it long back, I'll see if I can > remember that and post it later, in any case I don't want to fix that in > this draft.] Would be great to hear about the corner case. >> Section 5.2 Mitigation of Blind data injection attack >> >> [Clarification] >> Data that doesn't satisfy the new check in first paragraph >> MUST be discarded >> silently. Before RFC793 used to require an ACK to be sent >> back. This change >> is not sufficiently explained and lacks an obvious rationale. > > Good question, 793 implicitly tells that the following ACK range is > acceptable : > In other words an ACK value is acceptable if it is ((SND.UNA-(2^31-1)) > <= SEG.ACK <= SND.NXT). > > Anything > SND.NXT above would solicit an ACK to be sent back, this is > simply an ACK being sent for something that has not yet been actually > sent. I can only partly follow you here. My interpretation of the text in RFC793 tells us to send back a challenge-ACK to re-synchronize the connection. Not to ACK something not yet sent. > With this mitigation we are saying that the acceptability range becomes > : > > ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). > > Since we haven't accepted this segment we drop this silently to > distinguish with the above case. This is whole point. (old ACK versus an > ACK ack'ing data that is unsent) > > FWIW, this is been implemented and tested in some of the stacks and I > don't recall seeing any issues here. > > I agree that generating an ACK back is also fine and shouldn't pose any > issues. > > I will think about this a bit more and will get back since my opinion is > either way is fine. I don't doubt the extended check at all. I'm only concerned about its relationship to the ACK check in RFC793 (section 3.9, page 72, fifth check, ESTABLISHED STATE, first paragraph, last sentence) in two ways: a) tcp-secure section 5.2 essentially makes this check just tighter with the addition of the lower bound of (SND.UNA - MAX.SND.WND). Instead of being another check (with a as of yet unclear ordering relative to RFC793) this one could simply replace the one from RFC793. Would make the text and application of the check more clear. b) the change from a challenge-ACK (as my interpretation of RFC793) into a silent drop. >> The second related issue is where this check should be >> placed relative to >> RFC793 ordering? Before the fifth check, last sentence >> (page 72) "If the ACK >> acks something not yet sent (SEG.ACK > SND.NXT) then send >> an ACK, drop the >> segment, and return." or right after it? This has > > Should be before that, this is what we have tested with. Although I > can't think of on top of my head what would happen if we put after > that... Then it should only test for the lower bound, not the upper one. Otherwise the check from RFC793 would never trigger again. Everything is already filtered. 5a) (SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT [tcp-secure 5.2] 5b) SEG.ACK <= SND.NXT [RFC793, expression changed from negative to positive] >> implications on the response >> as tcpsecure requires to silently discard the segment. If >> it weren't for the >> silent discard the new tcpsecure check could simply >> replace/extend the fifth >> check from RFC793. > > Agreed. I think it is just a matter of perference and I think both > choices don't have any implications that I can see. My vote goes to replacing the fifth check of RFC793. Whether to silently ignore or sending a challenge-ACK I'm still undecided. -- Andre andre@FreeBSD.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 4 14:51:15 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9D228C137; Wed, 4 Jun 2008 14:51:14 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C204028C137 for ; Wed, 4 Jun 2008 14:51:13 -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 SlqvFDAPaXrm for ; Wed, 4 Jun 2008 14:51:12 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 35A6B3A6B1E for ; Wed, 4 Jun 2008 14:50:54 -0700 (PDT) Received: from [127.0.0.1] (32.sub-70-213-140.myvzw.com [70.213.140.32]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m54LoFmb027740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jun 2008 14:50:18 -0700 (PDT) Message-ID: <48470E16.5000802@isi.edu> Date: Wed, 04 Jun 2008 14:50:14 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Andre Oppermann References: <48432005.2070201@freebsd.org> <48449321.5000609@isi.edu> <4846FE85.4050009@freebsd.org> In-Reply-To: <4846FE85.4050009@freebsd.org> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: multipart/mixed; boundary="===============1430898292==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1430898292== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA9A25E1F2B8C8D0E2C64B5C5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA9A25E1F2B8C8D0E2C64B5C5 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > Joe Touch wrote: >> Hi, all, >> >> This is, IMO, a signal to review the recommendations in Section 1.1. I= =20 >> was always concerned that these mitigations would be misinterpreted as= =20 >> applying to hosts in general, which they do not. >=20 > I do not agree here. The recommendations in tcp-secure, IMHO, do apply= > to hosts in general and to servers in particular. Lets have a look at > some examples: IRC Servers, Jabber Servers, Usenet/NNTP Servers, > IMAP Servers, FTP Mirrors (rsync) as well as any other application that= > has long-lived and persistent connections. Long-lived persistent connections are only part of it; that fixes the=20 destination address and port. The source address and port need to be=20 known for the attack to be remotely useful. Source port randomization,=20 in specific, renders the attacks sufficiently unlikely. Detecting bursts = of RSTs aimed at a single connection also indicate attacks more=20 accurately and sufficiently, even if port randomization isn't used. >> The document, IMO, is insufficient in indicating therein that: >> >> - with source port randomization, the mitigations are not needed >> (port randomization provides a 2^15 strength amplification), >> even presuming source IP addresses are known >=20 > Only few do port randomization over the full range. Most limit it > to the high or low port range from which the applications draw. >=20 > Lets consider some examples: >=20 > Dest IP and port are pretty much a given. Source IP is probably known > to an attacker (like in an IRC or Jabber network). That leaves the sou= rce > port and seq#. Lets assume that the source port is in a fairly narrow > range of a couple of thousand ports either on the low side 1024-5000 or= > in the high range of 49000-60000. Without full port randomization it i= s > likely to be in the early port numbers. With a window of 64k (2^16) th= e > attack space shrinks to 2^16/2 =3D=3D 2^15 on average. That's 32k blin= d RST > packets per source port. With larger windows, which become more common= , > even less. Sounds almost trivially doable. Seems to me a lot smarter > to DDoS your favorite IRC network that way than through a traditional > brute force traffic attack. RFC4953 describes this issue in detail, and Figure 1 shows the required=20 RSTs. Multiplying these numbers by 3,000 (using even just the low=20 ports), or 15,000 (both ranges) renders the attacks effectively moot. A=20 few seconds of continuous RSTs or SYNs ought to tip off even the most=20 brain-damaged host that something is awry, IMO - moreso than=20 (incorrectly) inferring that RSTs in-window but not at the edge are=20 "incorrect". Source port randomization, like sequence number randomization, occurs=20 once at connection time rather than in the packet processing path, and=20 should be recommended anyway. > The [RST mitigation] ideally, with only rcv_nxt, increases the attack s= pace > to 2^31. The three +-1 window approach to somewhere between 2^23 and 2= ^26. >=20 > [SYN attack] of course is just as evil as RST attack and is completely = solved > by the challenge ACK (at the expense of potential bogus dupe-ack detect= ion > by the sender). >=20 > [Slipping data] into the window is made way more difficult with the ACK= check. > Here we go from 2^15 chance at 64k window to 2^32. Very valuable I'd s= ay. Data issues should be, IMO, solved by the use of true security, e.g.,=20 TLS, IPsec, or TCP MD5. > Coming back to the IRC server example an attacker can potentially take = over > a channel if he manages to insert the right command into a client-serve= r or > server-server stream. For the both the source IP and destination IP/po= rt > are known. To slip a malicious line I simply send a string terminating= the > previous line and add my line including line ending again. Then it doe= sn't > really matter which part of the stream I hit. Right - the data attack is more critical anyway. BGP reacts badly to=20 RSTs (removing routes); other systems just reconnect, so attacks there=20 have **far** less impact. >> - if source IP addresses are not known, the mitigations are not >> needed >=20 > For almost all examples above both endpoint plus at least one port > number are known. The lack of the other port number renders SYN and RST attacks much less=20 likely, and detecting large numbers of such messages would be a=20 sufficient signal that something is amiss. >> - the mitigations may increase the time needed to respond to >> a legitimate RST, incurring extra RTTs or retransmissions >> vs. an unmodified system >=20 > Which isn't a terrible price to pay. As far as my understanding > goes TCP is concerned with reliable transport of data, not absolutely > reliable abortions of the same through RSTs and SYNs. They do play > an important role in the functioning of the overall system but they > are not sensitive to a delay of a couple of milliseconds. RTTs these days can be upwards of a second or more, esp. when involving=20 satellite Internet connections, or over some data modems. >> - the mitigations are not a substitute for network or >> transport authentication, either of which obviate the need >> for the mitigations (yes, this is noted in the security >> considerations, but it's buried w.r.t. applicability) >=20 > There are some problems with transport authentication. IPSec does > authentication validation before the segment is checked by the TCP > layer.=20 There's nothing wrong with that; that's its intent. > TCP-MD5 can do better by doing all incoming segment checks > (seq#, ack#, window, timestamps) before doing the MD5 computation. It shouldn't; it should check the validity before checking the contents. = You're suggesting that packets with bad SPIs be checked against a=20 particular connection's detailed parameters? Why? If the SPI is correct, = it's a sufficient indication to invest in packet authentication, since=20 it's as likely to have come from an on-path attack, in which case any=20 TCP info might be in-spec (even if spoofed) anyway. > Nonetheless both can be used for exquisite CPU exhaustion attacks. That presumes software-based crypto. Further, they're not that exquisite = or necessarily CPU-intensive - using IPsec, e.g., requires guessing the=20 SPI. Tossing packets with invalid SPIs doesn't cost as much as full=20 validation. > The better my filter is in the TCP-MD5 case, the less exposure a > system has. Hence I argue that tcp-secure is actually helps TCP-MD5. TCP MD5 is somewhat deprecated (not officially, granted); its=20 replacement is under development in this WG. One of the key rules of the = replacement is to check the packet's authenticity before doing any TCP=20 processing. >> - the mitigations protect only off-path attacks; on-path >> attacks, such as ISPs shutting connections down deliberately, >> are not prevented by this mitigation (yes, also noted >> in security considerations, but again worth noting in >> applicability, and worth adding the ISP example, IMO) >=20 > Of course. So far nobody implied that it may protect again on-path > attacker. Explicitly stating it in the document may no hurt though. I wasn't suggesting you had implied it; I was just being complete in=20 suggestions that would be useful to sec 1.1. Joe --------------enigA9A25E1F2B8C8D0E2C64B5C5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRw4WE5f5cImnZrsRAjdNAJ95nGnS3QD4s/Nivq4bR4j9tX1kPgCfSXeZ QaZ2GtIFFZRUNgvDeF/cTCo= =EajY -----END PGP SIGNATURE----- --------------enigA9A25E1F2B8C8D0E2C64B5C5-- --===============1430898292== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1430898292==-- From tcpm-bounces@ietf.org Wed Jun 4 14:58:51 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A611C3A6AAF; Wed, 4 Jun 2008 14:58:51 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C01A3A6D35 for ; Wed, 4 Jun 2008 14:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTVIv0vJg3N3 for ; Wed, 4 Jun 2008 14:58:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 8DE1D3A67FA for ; Wed, 4 Jun 2008 14:58:49 -0700 (PDT) Received: from [127.0.0.1] (32.sub-70-213-140.myvzw.com [70.213.140.32]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m54LwZSB000180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jun 2008 14:58:38 -0700 (PDT) Message-ID: <4847100A.4060003@isi.edu> Date: Wed, 04 Jun 2008 14:58:34 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Andre Oppermann References: <48432005.2070201@freebsd.org> <48449321.5000609@isi.edu> <00BC7F35-5CE5-4142-AF30-7EDDB70A29D5@nokia.com> <4846FFFF.9090309@isi.edu> <48470949.3030904@networx.ch> In-Reply-To: <48470949.3030904@networx.ch> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: multipart/mixed; boundary="===============0287927131==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0287927131== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5EF15F93B198D14C920C6EC7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5EF15F93B198D14C920C6EC7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: =2E.. >> 2. adding these mitigations complicates the TCP implementation, >> and makes it less robust to legitimate RSTs, esp. in the >> presence of reordering; it can increase the time needed to >> reset a connection by one or more RTTs >=20 > Agreed for the second part about the potential for the time increase. > Not agreed to the first part. All kinds of mitigations make TCP > implementations more complex. Port randomization does, TCP-MD5 does, > IPsec does and so on. You can trust me on this one. ;-) IPsec has nothing to do with the TCP implementation; it may make the=20 stack more complex, but not TCP. Port randomization is a one-time event=20 during SYN creation, and should be easy to factor out as a separate=20 call. TCP MD5 is complex, but already implemented. The complexity I'm referring to is reflected in the exchange on details=20 and corner cases you've posted to this list. > Repeating myself: >=20 > The extra time it may take in an edge case is not terribly high. Most > RSTs will match and do their thing.=20 Actually, you've already indicated cases where that might not be true;=20 if RSTs are used to shut down typical connections "just in case", if any = of the in-transit data was lost, then these will trigger the ACK=20 exchange and extra RTT. This costs extra time, extra packets, and extra=20 processing on both ends - all for a NON MALICIOUS CASE. > As far as my understanding > goes TCP is concerned with reliable transport of data, not absolutely > reliable abortions of the same through RSTs and SYNs. They do play > an important role in the functioning of the overall system but they > are not sensitive to a delay of a couple of milliseconds. Correct; however, just because an endpoint didn't expect a packet does=20 not imply it is an attack either. That's the flaw in this system, IMO -=20 and a reason why bursts of RSTs or SYNs to the same addr/port pair are a = fairly clear indication of a problem, the filtering out of which would=20 make these mods completely unnecessary. Joe --------------enig5EF15F93B198D14C920C6EC7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRxAKE5f5cImnZrsRAiPSAKCJpspkNcolgMYJTKCWR+LgbfNF7gCfRVEv WURFnglQfawCSQy7sq2iYWI= =Tb4u -----END PGP SIGNATURE----- --------------enig5EF15F93B198D14C920C6EC7-- --===============0287927131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0287927131==-- From tcpm-bounces@ietf.org Wed Jun 4 15:54:59 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7123A68FB; Wed, 4 Jun 2008 15:54:59 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1177F3A6903 for ; Wed, 4 Jun 2008 15:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 ALEGzlG3k-02 for ; Wed, 4 Jun 2008 15:54:57 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by core3.amsl.com (Postfix) with ESMTP id 147053A6D34 for ; Wed, 4 Jun 2008 15:54:44 -0700 (PDT) Received: (qmail 1426 invoked from network); 4 Jun 2008 21:51:19 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Jun 2008 21:51:19 -0000 Message-ID: <48471D37.7080107@freebsd.org> Date: Thu, 05 Jun 2008 00:54:47 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Joe Touch References: <48432005.2070201@freebsd.org> <48449321.5000609@isi.edu> <4846FE85.4050009@freebsd.org> <48470E16.5000802@isi.edu> In-Reply-To: <48470E16.5000802@isi.edu> Cc: tcpm@ietf.org Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > Andre Oppermann wrote: >> Joe Touch wrote: >>> Hi, all, >>> >>> This is, IMO, a signal to review the recommendations in Section 1.1. >>> I was always concerned that these mitigations would be misinterpreted >>> as applying to hosts in general, which they do not. >> >> I do not agree here. The recommendations in tcp-secure, IMHO, do apply >> to hosts in general and to servers in particular. Lets have a look at >> some examples: IRC Servers, Jabber Servers, Usenet/NNTP Servers, >> IMAP Servers, FTP Mirrors (rsync) as well as any other application that >> has long-lived and persistent connections. > > Long-lived persistent connections are only part of it; that fixes the > destination address and port. The source address and port need to be > known for the attack to be remotely useful. Source port randomization, > in specific, renders the attacks sufficiently unlikely. Detecting bursts This is bandwidth dependent. May be true today. But may be not tomorrow. 32 bits of address space in computers was deemed sufficient for most systems, even larger ones, not long ago... > of RSTs aimed at a single connection also indicate attacks more > accurately and sufficiently, even if port randomization isn't used. AFAIK nobody has proposed such a RST detector in any I-D yet. That makes it a moot point. >>> The document, IMO, is insufficient in indicating therein that: >>> >>> - with source port randomization, the mitigations are not needed >>> (port randomization provides a 2^15 strength amplification), >>> even presuming source IP addresses are known >> >> Only few do port randomization over the full range. Most limit it >> to the high or low port range from which the applications draw. >> >> Lets consider some examples: >> >> Dest IP and port are pretty much a given. Source IP is probably known >> to an attacker (like in an IRC or Jabber network). That leaves the >> source >> port and seq#. Lets assume that the source port is in a fairly narrow >> range of a couple of thousand ports either on the low side 1024-5000 or >> in the high range of 49000-60000. Without full port randomization it is >> likely to be in the early port numbers. With a window of 64k (2^16) the >> attack space shrinks to 2^16/2 == 2^15 on average. That's 32k blind RST >> packets per source port. With larger windows, which become more common, >> even less. Sounds almost trivially doable. Seems to me a lot smarter >> to DDoS your favorite IRC network that way than through a traditional >> brute force traffic attack. > > RFC4953 describes this issue in detail, and Figure 1 shows the required > RSTs. Multiplying these numbers by 3,000 (using even just the low > ports), or 15,000 (both ranges) renders the attacks effectively moot. A > few seconds of continuous RSTs or SYNs ought to tip off even the most > brain-damaged host that something is awry, IMO - moreso than > (incorrectly) inferring that RSTs in-window but not at the edge are > "incorrect". Care to explain what software a not-brain-damaged host should run to detect this? And then what should the reaction be? Shutting down the connection? I don't think so. There is no counter-measure after you have detected a RST or SYN flood. What is one supposed to do? Filter these malicious packets? How? How can I differentiate them? Which brings us back a full 360 to tcp-secure. Ain't it so? > Source port randomization, like sequence number randomization, occurs > once at connection time rather than in the packet processing path, and > should be recommended anyway. I don't doubt source port randomization should be used. I'm arguing that your assertion of avoidable implementation complexity is moot. The implementation overhead is about the same. The runtime difference is essentially non-existent. >> The [RST mitigation] ideally, with only rcv_nxt, increases the attack >> space >> to 2^31. The three +-1 window approach to somewhere between 2^23 and >> 2^26. >> >> [SYN attack] of course is just as evil as RST attack and is completely >> solved >> by the challenge ACK (at the expense of potential bogus dupe-ack >> detection >> by the sender). >> >> [Slipping data] into the window is made way more difficult with the >> ACK check. >> Here we go from 2^15 chance at 64k window to 2^32. Very valuable I'd >> say. > > Data issues should be, IMO, solved by the use of true security, e.g., > TLS, IPsec, or TCP MD5. Careful. TLS doesn't help here. It sits above the TCP layer and a RST will abort the connection. You will be able to slip data into the stream and have it processed but TLS will get out of sync and abort the connection. >> Coming back to the IRC server example an attacker can potentially take >> over >> a channel if he manages to insert the right command into a >> client-server or >> server-server stream. For the both the source IP and destination IP/port >> are known. To slip a malicious line I simply send a string >> terminating the >> previous line and add my line including line ending again. Then it >> doesn't >> really matter which part of the stream I hit. > > Right - the data attack is more critical anyway. BGP reacts badly to > RSTs (removing routes); other systems just reconnect, so attacks there > have **far** less impact. Not true again. NNTP is just as vulnerable to a connection abort. Yes, it does reconnect (BGP does too) but it has to restart the feed again which involves a considerable amount of CPU and disk I/O churn. On top of it NNTP servers run at large bandwidths with large windows. IRC and Jabber servers are not that different. A net-split when the connection between servers is severed is considered very unlucky and to be avoided. It opens the window for all sorts of dirty tricks and channel takeovers that can happen during the split. This is why script kiddies so far like the brute force bandwidth exhaustion DDoS attack against IRC so much. Sure it reconnects after some time. However the damage is done with the disconnect. With Jabber a lot of presence information has to be exchanged again like with BGP. >>> - if source IP addresses are not known, the mitigations are not >>> needed >> >> For almost all examples above both endpoint plus at least one port >> number are known. > > The lack of the other port number renders SYN and RST attacks much less > likely, and detecting large numbers of such messages would be a > sufficient signal that something is amiss. [insert magic detection and response system -->here<--] >>> - the mitigations may increase the time needed to respond to >>> a legitimate RST, incurring extra RTTs or retransmissions >>> vs. an unmodified system >> >> Which isn't a terrible price to pay. As far as my understanding >> goes TCP is concerned with reliable transport of data, not absolutely >> reliable abortions of the same through RSTs and SYNs. They do play >> an important role in the functioning of the overall system but they >> are not sensitive to a delay of a couple of milliseconds. > > RTTs these days can be upwards of a second or more, esp. when involving > satellite Internet connections, or over some data modems. What is lost with a delayed RST vs. a prematurely aborted connection? >>> - the mitigations are not a substitute for network or >>> transport authentication, either of which obviate the need >>> for the mitigations (yes, this is noted in the security >>> considerations, but it's buried w.r.t. applicability) >> >> There are some problems with transport authentication. IPSec does >> authentication validation before the segment is checked by the TCP >> layer. > > There's nothing wrong with that; that's its intent. > >> TCP-MD5 can do better by doing all incoming segment checks >> (seq#, ack#, window, timestamps) before doing the MD5 computation. > > It shouldn't; it should check the validity before checking the contents. > You're suggesting that packets with bad SPIs be checked against a > particular connection's detailed parameters? Why? If the SPI is correct, > it's a sufficient indication to invest in packet authentication, since > it's as likely to have come from an on-path attack, in which case any > TCP info might be in-spec (even if spoofed) anyway. > >> Nonetheless both can be used for exquisite CPU exhaustion attacks. > > That presumes software-based crypto. Further, they're not that exquisite > or necessarily CPU-intensive - using IPsec, e.g., requires guessing the > SPI. Tossing packets with invalid SPIs doesn't cost as much as full > validation. You're right. SPI adds 16 bits of entropy before any crypto checks are done. And yes, software crypto is presumed. As are satellite connections and some data modems. >> The better my filter is in the TCP-MD5 case, the less exposure a >> system has. Hence I argue that tcp-secure is actually helps TCP-MD5. > > TCP MD5 is somewhat deprecated (not officially, granted); its > replacement is under development in this WG. One of the key rules of the > replacement is to check the packet's authenticity before doing any TCP > processing. Unless some SPI equivalent is included it makes a good attack vector. And how long will it take until all major vendors support it in their production ready and stable operating systems? >>> - the mitigations protect only off-path attacks; on-path >>> attacks, such as ISPs shutting connections down deliberately, >>> are not prevented by this mitigation (yes, also noted >>> in security considerations, but again worth noting in >>> applicability, and worth adding the ISP example, IMO) >> >> Of course. So far nobody implied that it may protect again on-path >> attacker. Explicitly stating it in the document may no hurt though. > > I wasn't suggesting you had implied it; I was just being complete in > suggestions that would be useful to sec 1.1. -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 4 16:01:47 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BF653A69AD; Wed, 4 Jun 2008 16:01:47 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58A23A69DB for ; Wed, 4 Jun 2008 16:01:45 -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] 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 nRJE5Cqmd6ng for ; Wed, 4 Jun 2008 16:01:44 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by core3.amsl.com (Postfix) with ESMTP id DBEC93A6938 for ; Wed, 4 Jun 2008 16:01:43 -0700 (PDT) Received: (qmail 1461 invoked from network); 4 Jun 2008 21:58:19 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Jun 2008 21:58:19 -0000 Message-ID: <48471EDA.5020504@freebsd.org> Date: Thu, 05 Jun 2008 01:01:46 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Joe Touch References: <48432005.2070201@freebsd.org> <48449321.5000609@isi.edu> <00BC7F35-5CE5-4142-AF30-7EDDB70A29D5@nokia.com> <4846FFFF.9090309@isi.edu> <48470949.3030904@networx.ch> <4847100A.4060003@isi.edu> In-Reply-To: <4847100A.4060003@isi.edu> Cc: tcpm@ietf.org Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > Andre Oppermann wrote: > ... >>> 2. adding these mitigations complicates the TCP implementation, >>> and makes it less robust to legitimate RSTs, esp. in the >>> presence of reordering; it can increase the time needed to >>> reset a connection by one or more RTTs >> >> Agreed for the second part about the potential for the time increase. >> Not agreed to the first part. All kinds of mitigations make TCP >> implementations more complex. Port randomization does, TCP-MD5 does, >> IPsec does and so on. You can trust me on this one. ;-) > > IPsec has nothing to do with the TCP implementation; it may make the > stack more complex, but not TCP. Port randomization is a one-time event > during SYN creation, and should be easy to factor out as a separate > call. TCP MD5 is complex, but already implemented. Port randomization is complex to implement. > The complexity I'm referring to is reflected in the exchange on details > and corner cases you've posted to this list. There are just as many corner cases with (true) port randomization. Have a look at its CVS history in the BSDs. Or Linux. Took a couple iterations. >> Repeating myself: >> >> The extra time it may take in an edge case is not terribly high. Most >> RSTs will match and do their thing. > > Actually, you've already indicated cases where that might not be true; > if RSTs are used to shut down typical connections "just in case", if any > of the in-transit data was lost, then these will trigger the ACK > exchange and extra RTT. This costs extra time, extra packets, and extra > processing on both ends - all for a NON MALICIOUS CASE. Normally the connection is in an idle state. It is primarily observed with web servers where either the client or server wants to do persistent connections and the other end does not. Or it times out. There would be no extra round-trip for the RST to be come effective. > > As far as my understanding >> goes TCP is concerned with reliable transport of data, not absolutely >> reliable abortions of the same through RSTs and SYNs. They do play >> an important role in the functioning of the overall system but they >> are not sensitive to a delay of a couple of milliseconds. > > Correct; however, just because an endpoint didn't expect a packet does > not imply it is an attack either. That's the flaw in this system, IMO - > and a reason why bursts of RSTs or SYNs to the same addr/port pair are a > fairly clear indication of a problem, the filtering out of which would > make these mods completely unnecessary. I'm all ears on your magic RST/SYN burst filter. -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 4 16:45:41 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B59483A6810; Wed, 4 Jun 2008 16:45:41 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425003A6810 for ; Wed, 4 Jun 2008 16:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvu2mM-V8Ep0 for ; Wed, 4 Jun 2008 16:45:32 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B5D0E3A67D1 for ; Wed, 4 Jun 2008 16:45:32 -0700 (PDT) Received: from [127.0.0.1] (32.sub-70-213-140.myvzw.com [70.213.140.32]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m54NjJtA000914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jun 2008 16:45:22 -0700 (PDT) Message-ID: <4847290E.8070605@isi.edu> Date: Wed, 04 Jun 2008 16:45:18 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Andre Oppermann References: <48432005.2070201@freebsd.org> <48449321.5000609@isi.edu> <4846FE85.4050009@freebsd.org> <48470E16.5000802@isi.edu> <48471D37.7080107@freebsd.org> In-Reply-To: <48471D37.7080107@freebsd.org> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: multipart/mixed; boundary="===============0637757738==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0637757738== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig14FF27E632276F11E7A174E7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig14FF27E632276F11E7A174E7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Andre, Andre Oppermann wrote: =2E.. >> Long-lived persistent connections are only part of it; that fixes the = >> destination address and port. The source address and port need to be=20 >> known for the attack to be remotely useful. Source port randomization,= =20 >> in specific, renders the attacks sufficiently unlikely. Detecting burs= ts=20 >=20 > This is bandwidth dependent. May be true today. But may be not > tomorrow. 32 bits of address space in computers was deemed sufficient > for most systems, even larger ones, not long ago... Agreed. However, first, we're talking about the connection between two=20 machines, and the transport bandwidth between them, not just the channel = capacity. Few machines can sustain more than 1Gbps right now. Second, all these mitigations become moot if you deploy appropriate=20 authentication. They're also moot if off-path attacks are mitigated by=20 other means, e.g., path checks and ingress filtering. >> of RSTs aimed at a single connection also indicate attacks more=20 >> accurately and sufficiently, even if port randomization isn't used. >=20 > AFAIK nobody has proposed such a RST detector in any I-D yet. That > makes it a moot point. RST detection doesn't need an ID. It needs a template in SNORT or somesuc= h. >> RFC4953 describes this issue in detail, and Figure 1 shows the=20 >> required RSTs. Multiplying these numbers by 3,000 (using even just the= =20 >> low ports), or 15,000 (both ranges) renders the attacks effectively=20 >> moot. A few seconds of continuous RSTs or SYNs ought to tip off even=20 >> the most brain-damaged host that something is awry, IMO - moreso than = >> (incorrectly) inferring that RSTs in-window but not at the edge are=20 >> "incorrect". >=20 > Care to explain what software a not-brain-damaged host should run to > detect this?=20 Count RSTs received by a TCP that are out of window. If you get more=20 than a few (3 maybe), wouldn't you assume someone was trying to attack? > And then what should the reaction be? Shutting down the > connection? Ignoring RSTs for some period of time, e.g., a few minutes. That sort of = thing strengthens the system quite a bit, and ONLY when it is under=20 attack. It can be implemented as a filter outside of TCP too. >> Source port randomization, like sequence number randomization, occurs = >> once at connection time rather than in the packet processing path, and= =20 >> should be recommended anyway. >=20 > I don't doubt source port randomization should be used. I'm arguing > that your assertion of avoidable implementation complexity is moot. > The implementation overhead is about the same. The runtime difference > is essentially non-existent. The difference is that picking a random source port doesn't change the=20 TCP specification - it's already in-spec. Further, it can be implemented = in ways that prevent modifying the code all over the place. >>> [Slipping data] into the window is made way more difficult with the=20 >>> ACK check. >>> Here we go from 2^15 chance at 64k window to 2^32. Very valuable I'd= =20 >>> say. >> >> Data issues should be, IMO, solved by the use of true security, e.g., = >> TLS, IPsec, or TCP MD5. >=20 > Careful. TLS doesn't help here. It sits above the TCP layer and a > RST will abort the connection. You will be able to slip data into > the stream and have it processed but TLS will get out of sync and > abort the connection. AOK; if TLS aborts connections due to bad data, then it's a bad=20 solution. Fair enough; use IPsec or TCP MD5. >>> Coming back to the IRC server example an attacker can potentially=20 >>> take over >>> a channel if he manages to insert the right command into a=20 >>> client-server or >>> server-server stream. For the both the source IP and destination=20 >>> IP/port >>> are known. To slip a malicious line I simply send a string=20 >>> terminating the >>> previous line and add my line including line ending again. Then it=20 >>> doesn't >>> really matter which part of the stream I hit. >> >> Right - the data attack is more critical anyway. BGP reacts badly to=20 >> RSTs (removing routes); other systems just reconnect, so attacks there= =20 >> have **far** less impact. >=20 > Not true again. NNTP is just as vulnerable to a connection abort. Yes= , > it does reconnect (BGP does too) but it has to restart the feed again > which involves a considerable amount of CPU and disk I/O churn. On top= > of it NNTP servers run at large bandwidths with large windows. That's a fine reason to fix NNTP, or to protect it with something more=20 appropriate. > IRC and Jabber servers are not that different. A net-split when the > connection between servers is severed is considered very unlucky and > to be avoided. It opens the window for all sorts of dirty tricks and > channel takeovers that can happen during the split. This is why script= > kiddies so far like the brute force bandwidth exhaustion DDoS attack > against IRC so much. Sure it reconnects after some time. However the > damage is done with the disconnect. With Jabber a lot of presence > information has to be exchanged again like with BGP. If an app depends that much on a connection staying up, then SECURE the=20 thing. All of your concerns point to bad deployment practices. >>>> - if source IP addresses are not known, the mitigations are not >>>> needed >>> >>> For almost all examples above both endpoint plus at least one port >>> number are known. >> >> The lack of the other port number renders SYN and RST attacks much=20 >> less likely, and detecting large numbers of such messages would be a=20 >> sufficient signal that something is amiss. >=20 [insert magic detection and response system -->snort<--] Done. >>>> - the mitigations may increase the time needed to respond to >>>> a legitimate RST, incurring extra RTTs or retransmissions >>>> vs. an unmodified system >>> >>> Which isn't a terrible price to pay. As far as my understanding >>> goes TCP is concerned with reliable transport of data, not absolutely= >>> reliable abortions of the same through RSTs and SYNs. They do play >>> an important role in the functioning of the overall system but they >>> are not sensitive to a delay of a couple of milliseconds. >> >> RTTs these days can be upwards of a second or more, esp. when=20 >> involving satellite Internet connections, or over some data modems. >=20 > What is lost with a delayed RST vs. a prematurely aborted connection? Large delays of RSTs can increase the time until new connections can be=20 established, e.g., if port pairs are reused (sending a RST does not=20 require that either side end up in a TIME_WAIT -- unfortunately). It's also the additional packets exchanged and the complexity of the=20 system that are the issue - notably when an attack is NOT occurring. >>>> - the mitigations are not a substitute for network or >>>> transport authentication, either of which obviate the need >>>> for the mitigations (yes, this is noted in the security >>>> considerations, but it's buried w.r.t. applicability) >>> >>> There are some problems with transport authentication. IPSec does >>> authentication validation before the segment is checked by the TCP >>> layer.=20 >> >> There's nothing wrong with that; that's its intent. >> >>> TCP-MD5 can do better by doing all incoming segment checks >>> (seq#, ack#, window, timestamps) before doing the MD5 computation. >> >> It shouldn't; it should check the validity before checking the=20 >> contents. You're suggesting that packets with bad SPIs be checked=20 >> against a particular connection's detailed parameters? Why? If the SPI= =20 >> is correct, it's a sufficient indication to invest in packet=20 >> authentication, since it's as likely to have come from an on-path=20 >> attack, in which case any TCP info might be in-spec (even if spoofed) = >> anyway. > > >>> Nonetheless both can be used for exquisite CPU exhaustion attacks. >> >> That presumes software-based crypto. Further, they're not that=20 >> exquisite or necessarily CPU-intensive - using IPsec, e.g., requires=20 >> guessing the SPI. Tossing packets with invalid SPIs doesn't cost as=20 >> much as full validation. >=20 > You're right. SPI adds 16 bits of entropy before any crypto checks > are done. And yes, software crypto is presumed. As are satellite > connections and some data modems. SPIs are 32 bits. >>> The better my filter is in the TCP-MD5 case, the less exposure a >>> system has. Hence I argue that tcp-secure is actually helps TCP-MD5.= >> >> TCP MD5 is somewhat deprecated (not officially, granted); its=20 >> replacement is under development in this WG. One of the key rules of=20 >> the replacement is to check the packet's authenticity before doing any= =20 >> TCP processing. >=20 > Unless some SPI equivalent is included it makes a good attack vector. The equivalent is source port randomization. > And how long will it take until all major vendors support it in their > production ready and stable operating systems? Port randomization is a lot easier to implement and is already deployed=20 (in FreeBSD and Linux, e.g.); see appendix A of=20 draft-ietf-tsvwg-port-randomization-01.txt. Joe --------------enig14FF27E632276F11E7A174E7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRykOE5f5cImnZrsRAoOuAKDXUi1WYNAyLjvJWYrh8YSBmRQZRwCdGC0J FpdtpnLPsMQUFhv5MSQ34I8= =B4sP -----END PGP SIGNATURE----- --------------enig14FF27E632276F11E7A174E7-- --===============0637757738== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0637757738==-- From tcpm-bounces@ietf.org Wed Jun 4 16:53:09 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420193A6880; Wed, 4 Jun 2008 16:53:09 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C8C3A6880 for ; Wed, 4 Jun 2008 16:53:08 -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 y30hvVLhKLk6 for ; Wed, 4 Jun 2008 16:53:07 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0D0243A6810 for ; Wed, 4 Jun 2008 16:53:07 -0700 (PDT) Received: from [127.0.0.1] (32.sub-70-213-140.myvzw.com [70.213.140.32]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m54NmrOd001563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jun 2008 16:48:57 -0700 (PDT) Message-ID: <484729E5.4010101@isi.edu> Date: Wed, 04 Jun 2008 16:48:53 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Andre Oppermann References: <48432005.2070201@freebsd.org> <48449321.5000609@isi.edu> <00BC7F35-5CE5-4142-AF30-7EDDB70A29D5@nokia.com> <4846FFFF.9090309@isi.edu> <48470949.3030904@networx.ch> <4847100A.4060003@isi.edu> <48471EDA.5020504@freebsd.org> In-Reply-To: <48471EDA.5020504@freebsd.org> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: multipart/mixed; boundary="===============1207349757==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1207349757== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDE7934513D212DCED37C05CB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDE7934513D212DCED37C05CB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > Joe Touch wrote: >> Andre Oppermann wrote: >> ... >>>> 2. adding these mitigations complicates the TCP implementation, >>>> and makes it less robust to legitimate RSTs, esp. in the >>>> presence of reordering; it can increase the time needed to >>>> reset a connection by one or more RTTs >>> >>> Agreed for the second part about the potential for the time increase.= >>> Not agreed to the first part. All kinds of mitigations make TCP >>> implementations more complex. Port randomization does, TCP-MD5 does,= >>> IPsec does and so on. You can trust me on this one. ;-) >> >> IPsec has nothing to do with the TCP implementation; it may make the=20 >> stack more complex, but not TCP. Port randomization is a one-time=20 >> event during SYN creation, and should be easy to factor out as a=20 >> separate call. TCP MD5 is complex, but already implemented. >=20 > Port randomization is complex to implement. It's already implemented. See my other reply. >> The complexity I'm referring to is reflected in the exchange on=20 >> details and corner cases you've posted to this list. >=20 > There are just as many corner cases with (true) port randomization. > Have a look at its CVS history in the BSDs. Or Linux. Took a couple > iterations. Multiple iterations is not an indication of difficult corner cases. >>> Repeating myself: >>> >>> The extra time it may take in an edge case is not terribly high. Mos= t >>> RSTs will match and do their thing.=20 >> >> Actually, you've already indicated cases where that might not be true;= =20 >> if RSTs are used to shut down typical connections "just in case", if=20 >> any of the in-transit data was lost, then these will trigger the ACK=20 >> exchange and extra RTT. This costs extra time, extra packets, and=20 >> extra processing on both ends - all for a NON MALICIOUS CASE. >=20 > Normally the connection is in an idle state. It is primarily observed > with web servers where either the client or server wants to do persiste= nt > connections and the other end does not. Or it times out. There would = be > no extra round-trip for the RST to be come effective. It's also been observed in web servers that want to reduce the amount of = TIME_WAIT state they hold - and thus kernel memory they tie up - for=20 connections that clients close by normal means. Joe --------------enigDE7934513D212DCED37C05CB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRynlE5f5cImnZrsRAuSDAKCszEgKvQO3i+qafF5zCkJqR2UjrQCg4HUx XRUG7yxFWDPMjh9gWcOsCjs= =4SO3 -----END PGP SIGNATURE----- --------------enigDE7934513D212DCED37C05CB-- --===============1207349757== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1207349757==-- From tcpm-bounces@ietf.org Mon Jun 9 23:33:22 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0636E3A6913; Mon, 9 Jun 2008 23:33:22 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE553A6913 for ; Mon, 9 Jun 2008 23:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_33=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 cOBtidSPwCWj for ; Mon, 9 Jun 2008 23:33:19 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 557693A6840 for ; Mon, 9 Jun 2008 23:33:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,615,1204531200"; d="scan'208";a="111082983" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2008 23:33:38 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5A6XcLF012451; Mon, 9 Jun 2008 23:33:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5A6XbuV017754; Tue, 10 Jun 2008 06:33:38 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); Mon, 9 Jun 2008 23:33:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 23:32:45 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5805498496@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <48470580.1010408@freebsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Q&C regarding tcpsecure-09 recommendations Thread-Index: AcjGh+CFfY1L2PnZR/C35IOhDnwLdgENCMmw References: <48432005.2070201@freebsd.org> <0C53DCFB700D144284A584F54711EC5805449484@xmb-sjc-21c.amer.cisco.com> <48470580.1010408@freebsd.org> From: "Anantha Ramaiah (ananth)" To: "Andre Oppermann" X-OriginalArrivalTime: 10 Jun 2008 06:33:37.0700 (UTC) FILETIME=[EA378640:01C8CAC3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4571; t=1213079618; x=1213943618; 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]=20Q&C=20regarding=20tcpsecure-09 =20recommendations |Sender:=20; bh=5WZkNW5/xUGq2tv06SJQzJs5EJGyqK+sV66qP3lcaoc=; b=ee5Djz/KCDnlO2clPybzGJJnX6D1yzx9Cu+Tyab9/eQ3JGq6E+neHC5baf wLQQrVrvrd5G4GEHEHKxLHwKcfbkW+XBVXwMTeUEjcLoVRDfdlYGFPf3Wx64 FqdC0+lBfPipVZoGyoqtAj1kfcMIi4WJtnVv4Ru6wvleTxsX2YAAg=; 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] Q&C regarding tcpsecure-09 recommendations 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Andre, Sorry about the late response, I had marked it for later response and got to it just now. > > This +-1 extension is done to accept the initial RST w/o > having to send a challenge ACK. It has been observed by my > fellow FreeBSD developer Qing Li that certain system send the > RST to weird off-by-one places in either direction. > > A surprisingly large number of RSTs are generated by socket > closes of connections that actually were in use shortly > before. Depending on the exact timing of the connection > teardown the RST is not sent in response to some incoming > segment but from the tcpcb state to inform the other end of > the immediate termination of this connection. Ok, but do you see the need to mention this +-1 case in the draft, since the mitigation is the same from all the cases. Whether or not to send the challenge ACK for the cases you mention should be treated as an optimization and should be left to implementers choice, IMO. >> This seems to be incorrectly transcribed. > > Good catch, I'll change it. I thought I had removed it before. > > [I think I know the reason why this = got added, this is one of the > corner cases which we have fixed it long back, I'll see if I can > remember that and post it later, in any case I don't want to fix that > in this draft.] > > Would be great to hear about the corner case. I'll mention this in a separate email, I need to dig up my notes since on top of my head I am unable to construct it. > > I can only partly follow you here. My interpretation of the > text in RFC793 tells us to send back a challenge-ACK to > re-synchronize the connection. > Not to ACK something not yet sent. Correct, I should have been clear : 793 tells : if you receive an ACK for unsent data send a corrective ACK to re-sync the connection. > > I don't doubt the extended check at all. I'm only concerned > about its relationship to the ACK check in RFC793 (section > 3.9, page 72, fifth check, ESTABLISHED STATE, first > paragraph, last sentence) in two ways: > > a) tcp-secure section 5.2 essentially makes this check just > tighter with > the addition of the lower bound of (SND.UNA - > MAX.SND.WND). Instead > of being another check (with a as of yet unclear > ordering relative > to RFC793) this one could simply replace the one from > RFC793. Would > make the text and application of the check more clear. > > b) the change from a challenge-ACK (as my interpretation of > RFC793) into > a silent drop. Actually I did a deeper look into the implementation what we have and we are infact (for the same reasons) which you mention above dropping the segment and sending the corrective ACK. > > >> The second related issue is where this check should be placed > >> relative to > >> RFC793 ordering? Before the fifth check, last sentence > (page 72) > >> "If the ACK > >> acks something not yet sent (SEG.ACK > SND.NXT) then > send an ACK, > >> drop the > >> segment, and return." or right after it? This has > > > > Should be before that, this is what we have tested with. Although I > > can't think of on top of my head what would happen if we put after > > that... > > Then it should only test for the lower bound, not the upper one. > Otherwise the check from RFC793 would never trigger again. > Everything is already filtered. Correct. Something like this : if (TCP_SEQ_RANGE (TCB.SNDUNA, SEG.ACK, TCB.SNDNXT) { // new acknowledgement, do the necessary action } else { if TCP_SEQ_RANGE ((TCB.SNDUNA - max_window), SEG.ACK, TCB.SNDUNA) { do nothing; /* accept it */ } else { discard the segment; send corrective ACK; // this step is the same as what RFC is saying today. } } Where max_window is hardcoded to some value [ taking into account window scaling as well] .... .... process the segment text. > > My vote goes to replacing the fifth check of RFC793. Whether > to silently ignore or sending a challenge-ACK I'm still undecided. Sure, like I said our implementation already does what you are mentioning. We do send the corrective ACK for tcp-secure case as well. So I have no problems mentioning that in the document. I can add this in the document. Good comments, thanks! -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 11 05:50:35 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A42F3A67E2; Wed, 11 Jun 2008 05:50:35 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E9C3A6780 for ; Wed, 11 Jun 2008 05:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=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 ByCLIb5gepbp for ; Wed, 11 Jun 2008 05:50:32 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by core3.amsl.com (Postfix) with ESMTP id 6B8EE3A63D2 for ; Wed, 11 Jun 2008 05:50:30 -0700 (PDT) Received: (qmail 36052 invoked from network); 11 Jun 2008 11:46:11 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jun 2008 11:46:11 -0000 Message-ID: <484FCA2C.2020600@freebsd.org> Date: Wed, 11 Jun 2008 14:50:52 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: tcpm@ietf.org Subject: [tcpm] Window update algorithm differences 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org There is some considerable disagreement on the correctness of the original window update test in various operating systems. Here is an overview of the current approaches used by the popular and open source TCP implementations: RFC793: section 3.9, page 72 SND.UNA < SEG.ACK =< SND.NXT, update window but not SND.WU.[SEQ|ACK] (SND.WU.SEQ < SEG.SEQ or (SND.WU.SEQ = SEG.SEQ and SND.WU.ACK =< SEG.ACK)) update everything. Stevens Vol.2: section 29.7, page 981-983 FreeBSD: src/sys/netinet/tcp_input.c, rev. 1.376 OpenBSD: src/sys/netinet/tcp_input.c, rev. 1.215 NetBSD: src/sys/netinet/tcp_input.c, rev. 1.287 SEG.SEQ > SND.WU.SEQ or (SEG.SEQ = SND.WU.SEQ and (SEG.ACK > SND.WU.ACK or (SEG.ACK = SND.WU.ACK and SEG.WND > SND.WND))) update everything. OpenSolaris: src/uts/common/inet/tcp/tcp.c, @swnd_update, rev. 6707 SEG.ACK > SND.WU.ACK or SEG.SEQ > SND.WU.SEQ or (SEG.SEQ = SND.WU.SEQ and SEQ.WND > SND.WND) update everything. Linux: net/ipv4/tcp_input.c, @tcp_ack_update_window(), rel. 2.6.25 SEG.ACK > SND.UNA or SEG.SEQ > SND.WU.SEQ or (SEG.SEQ = SND.WU.SEQ and SEG.WND > SND.WND) update everything. The OpenSolaris code contains some comments about being better in case of bi-directional traffic and alleged problems with the RFC793 method. The Linux code contains some general comments about the incorrectness of the BSD method without further elaboration. The obvious question is which one is correct or better than the others? Lets have a look at the basic requirement of the send window update. o Only newer than already seen segment should update the send window to prevent old and outdated information being used. o All evolves around how to reliably detect newer updates. Lets have a look at what makes a segment new: o When using timestamps, either the reflected TS is higher than the last one we got (we're sending data), or the TS from the other end is newer than what we currently reflect (we're receiving data or a window update). Problem: what to do when the round trip time is faster than the timestamp resolution? Fall back to the SEQ and ACK checks. SEG.TSECR > TS_RECENT_AGE or SEG.TSVAL > TS_RECENT o Data we sent has been ack'ed. Problem: None really. Doesn't trigger on old retransmits or out-of order. SEG.ACK > SND.UNA (and implicit SEG.ACK <= SND.NXT) o We receive new data. Problem: out-of order into reassembly queue, retransmits of missing segments, reordering of segments. Retransmit contains newer value. SEG.SEQ > RCV.NXT o No data sent or received but window increases. Problem: old delayed segment. Only allow if window increases. SEG.WND > SND.WND Hence I propose the following updated acceptable window update check: [1] (TS and SEG.TSECR > TS_RECENT_AGE or SEG.TSVAL > TS_RECENT or [2] SEG.ACK > SND.UNA or [3] (SEG.SEQ > SND.WU.SEQ and SEG.ACK >= SND.UNA) or [4] (SEG.SEQ = SND.WU.SEQ and SEG.ACK = SND.UNA and SEG.WND > SND.WND) SND.WND <- SEG.WND [5] SEG.SEQ > SND.WU.SEQ SND.WU.SEQ <- SEG.SEQ [6] (SND.WU.ACK <- SEG.ACK) [1] If either timestamp is newer than what we've already seen this is a new segment and the window it contains is certain to be valid without any further checks. [2] This is reliable indicator of a genuine window update. With the arrival of new data that is ack'ed the window also has been updated. [3] A higher sequence number tells us new data was received but if the ACK is lower than what we've already seen it must be a retransmit. [4] A pure window update if the sequence number is the same, the ACK is not lower than what we've already seen and the advertised window is larger than the one we had. [5] Only change the last update that gave us a window update if it is higher than what we have. This prevents retransmitted or reordered segments without a new ACK from updating our window. With timestamps we can reliably differentiate retransmits from out-of order segments. [6] Tracking the last ACK that updated the window has become unnecessary. SND.WU.ACK is also known as SND.WL2. Cases: o In unidirectional send we trigger always on [2] when our data is ack'ed. o In unidirectional receive we trigger on [3] for in-order segments. Out of order segments do not update the window unless they advance SND.WU.SEQ. Retransmits are not detected unless timestamps are enabled. In that case [1] triggers if the RTT is larger than the resolution of the timestamp clock. Otherwise window updates will resume when all missing segments are retransmitted and new segments beyond SND.WU.SEQ arrive. o In bidirectional traffic we trigger on [3] and [2]. If the transfer has loss or is re-ordered in either or both directions we also trigger in all important cases due to [2] when new data was ack'ed, and [3] new data with an up to date ACK is received. Above all the timestamp check allows all new segments no matter what order they are in. Feedback and pointing out of mistakes are welcome. BTW: TAC's are gone for good! -- Andre andre@FreeBSD.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jun 13 05:46:01 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD48F3A684C; Fri, 13 Jun 2008 05:46:00 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7FD733A684C; Fri, 13 Jun 2008 05:45: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: <20080613124507.7FD733A684C@core3.amsl.com> Date: Fri, 13 Jun 2008 05:45:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-uto-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP User Timeout Option Author(s) : L. Eggert, F. Gont Filename : draft-ietf-tcpm-tcp-uto-09.txt Pages : 17 Date : 2008-06-13 The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option - the TCP User Timeout Option - that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-uto-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-13053846.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Fri Jun 13 07:40:42 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED353A6920; Fri, 13 Jun 2008 07:40:42 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977E53A6924 for ; Fri, 13 Jun 2008 07:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 5Yhfk1umIxSs for ; Fri, 13 Jun 2008 07:40:40 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A5C093A6920 for ; Fri, 13 Jun 2008 07:40:40 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5DEZJkb011891 for ; Fri, 13 Jun 2008 09:41:08 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 17:40:30 +0300 Received: from net-92.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 17:40:30 +0300 Message-Id: <9AF7DF3F-643E-4E44-BA0F-6934CC0F39F4@nokia.com> From: Lars Eggert To: tcpm Extensions WG In-Reply-To: <20080613124507.7FD733A684C@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 13 Jun 2008 17:40:26 +0300 References: <20080613124507.7FD733A684C@core3.amsl.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 13 Jun 2008 14:40:30.0673 (UTC) FILETIME=[6DBEB410:01C8CD63] X-Nokia-AV: Clean Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-uto-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org FYI, I resubmitted this on request from our chairs, who are getting ready to request publication of this draft. (Magnus is the AD for this one, obviously.) No technical changes, one referenced ID is now an RFC and I fixed a language nit. Lars On 2008-6-13, at 15:45, ext Internet-Drafts@ietf.org wrote: > Title : TCP User Timeout Option > Author(s) : L. Eggert, F. Gont > Filename : draft-ietf-tcpm-tcp-uto-09.txt _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 16 01:23:49 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6503A6A6C; Mon, 16 Jun 2008 01:23:49 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB433A6A68 for ; Mon, 16 Jun 2008 01:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 HPXcIwhWhny7 for ; Mon, 16 Jun 2008 01:23:44 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 5EBF33A6A6C for ; Mon, 16 Jun 2008 01:23:44 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5G8O0kZ001143; Mon, 16 Jun 2008 11:24:14 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 11:24:09 +0300 Received: from net-82.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 11:24:08 +0300 Message-Id: From: Lars Eggert To: tcpm Extensions WG Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 16 Jun 2008 11:24:03 +0300 X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 16 Jun 2008 08:24:08.0848 (UTC) FILETIME=[592AE900:01C8CF8A] X-Nokia-AV: Clean Cc: tcpm-chairs@tools.ietf.org, David Borman , Wesley Eddy Subject: [tcpm] new TCPM chairs 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi, I've decided on Wes Eddy and Dave Borman as the new chairs for TCPM to follow after Ted and Mark. I'm happy that we were able to find folks with the experience needed for chairing this important group. I'd also like to thank everyone who volunteered to be considered for this position. Please join me in thanking Mark and Ted for their long years of long years of exemplary service to the community! Thanks, Lars PS: Mark and Ted will finish a few ongoing WG last calls, in order to hand over the WG in a well-defined state to Wes and Dave. The official handover will be after that has happened, i.e., in a week or two. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jun 20 12:08:06 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2E43A691D; Fri, 20 Jun 2008 12:08:06 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FECC3A691D for ; Fri, 20 Jun 2008 12:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 Xkx6utN3sr06 for ; Fri, 20 Jun 2008 12:08:03 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id B248A3A6A3B for ; Fri, 20 Jun 2008 12:08:03 -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 m5KJ7qsw022733; Fri, 20 Jun 2008 12:07:53 -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, 20 Jun 2008 12:07:51 -0700 Received: from dab-restive.wrs.com ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jun 2008 12:07:51 -0700 Message-Id: <9D24B50F-5ABC-4709-9FFA-956CAC9BA9C7@windriver.com> From: David Borman To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 20 Jun 2008 14:07:49 -0500 X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 20 Jun 2008 19:07:51.0916 (UTC) FILETIME=[EFF662C0:01C8D308] Cc: Wes Eddy , Mark Allman Subject: [tcpm] Early-retransmit as a WG item 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At a previous IETF meeting there was support for adopting the Early Retransmit document as a WG item, but it was never taken to the mailing list for verification. The last version (draft-allman-tcp- early-rexmt-05.txt) has expired, though I assume the authors will submit a new version. Are there any objections to adopting this as a TCPM WG item? -David Borman, TCPM co-chair _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 23 11:56:51 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EBF63A68B5; Mon, 23 Jun 2008 11:56:51 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E78B3A68B5 for ; Mon, 23 Jun 2008 11:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.46 X-Spam-Level: X-Spam-Status: No, score=0.46 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=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 uE-MlhHnL3Gc for ; Mon, 23 Jun 2008 11:56:49 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [IPv6:2001:5e8:1:3a::64]) by core3.amsl.com (Postfix) with ESMTP id 7D90F3A6838 for ; Mon, 23 Jun 2008 11:56:48 -0700 (PDT) Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer1.psc.edu (8.14.2/8.13.3) with ESMTP id m5NIukqs020791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2008 14:56:46 -0400 (EDT) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id m5NIukoQ011549; Mon, 23 Jun 2008 14:56:46 -0400 Date: Mon, 23 Jun 2008 14:56:46 -0400 (EDT) From: Matt Mathis To: Andre Oppermann In-Reply-To: <484FCA2C.2020600@freebsd.org> Message-ID: References: <484FCA2C.2020600@freebsd.org> MIME-Version: 1.0 Cc: tcpm@ietf.org Subject: Re: [tcpm] Window update algorithm differences 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I don't recall all of the details (since it is part of the spec that I don't normally deal with) but I believe that problem has to do with deadlocks caused by lost window updates when zero window probing. The problem is that zero window probes and keep alives have to update SND.WND, even though they are technically out of window (but by just one byte). I believe the failure case is if both directions go into zero window probing, and then both ends read queued data (freeing window space) but neither end can send data in window to cause the other end to see its new window announcement. I think the fix is to make first window check smidgen wide, do the window update processing, and then exclude the edge case further down, such that the net window is the same as 793, as updated by 1323. I recall a comment someplace about "accepting window updates from out of order segments", which is the key. I hope this helps, --MM-- ------------------------------------------- Matt Mathis http://staff.psc.edu/mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Wed, 11 Jun 2008, Andre Oppermann wrote: > There is some considerable disagreement on the correctness of the original > window update test in various operating systems. Here is an overview of > the current approaches used by the popular and open source TCP implementations: > > RFC793: section 3.9, page 72 > SND.UNA < SEG.ACK =< SND.NXT, update window but not SND.WU.[SEQ|ACK] > (SND.WU.SEQ < SEG.SEQ or (SND.WU.SEQ = SEG.SEQ and SND.WU.ACK =< SEG.ACK)) > update everything. > > Stevens Vol.2: section 29.7, page 981-983 > FreeBSD: src/sys/netinet/tcp_input.c, rev. 1.376 > OpenBSD: src/sys/netinet/tcp_input.c, rev. 1.215 > NetBSD: src/sys/netinet/tcp_input.c, rev. 1.287 > SEG.SEQ > SND.WU.SEQ or (SEG.SEQ = SND.WU.SEQ and (SEG.ACK > SND.WU.ACK or > (SEG.ACK = SND.WU.ACK and SEG.WND > SND.WND))) update everything. > > OpenSolaris: src/uts/common/inet/tcp/tcp.c, @swnd_update, rev. 6707 > SEG.ACK > SND.WU.ACK or SEG.SEQ > SND.WU.SEQ or > (SEG.SEQ = SND.WU.SEQ and SEQ.WND > SND.WND) update everything. > > Linux: net/ipv4/tcp_input.c, @tcp_ack_update_window(), rel. 2.6.25 > SEG.ACK > SND.UNA or SEG.SEQ > SND.WU.SEQ or > (SEG.SEQ = SND.WU.SEQ and SEG.WND > SND.WND) update everything. > > The OpenSolaris code contains some comments about being better in case > of bi-directional traffic and alleged problems with the RFC793 method. > The Linux code contains some general comments about the incorrectness > of the BSD method without further elaboration. > > The obvious question is which one is correct or better than the others? > > Lets have a look at the basic requirement of the send window update. > > o Only newer than already seen segment should update the send window > to prevent old and outdated information being used. > > o All evolves around how to reliably detect newer updates. > > Lets have a look at what makes a segment new: > > o When using timestamps, either the reflected TS is higher than the > last one we got (we're sending data), or the TS from the other end > is newer than what we currently reflect (we're receiving data or > a window update). > Problem: what to do when the round trip time is faster than the > timestamp resolution? Fall back to the SEQ and ACK checks. > > SEG.TSECR > TS_RECENT_AGE or SEG.TSVAL > TS_RECENT > > o Data we sent has been ack'ed. > Problem: None really. Doesn't trigger on old retransmits or out-of > order. > > SEG.ACK > SND.UNA (and implicit SEG.ACK <= SND.NXT) > > o We receive new data. > Problem: out-of order into reassembly queue, retransmits of missing > segments, reordering of segments. Retransmit contains newer value. > > SEG.SEQ > RCV.NXT > > o No data sent or received but window increases. > Problem: old delayed segment. Only allow if window increases. > > SEG.WND > SND.WND > > > Hence I propose the following updated acceptable window update check: > > [1] (TS and SEG.TSECR > TS_RECENT_AGE or SEG.TSVAL > TS_RECENT or > [2] SEG.ACK > SND.UNA or > [3] (SEG.SEQ > SND.WU.SEQ and SEG.ACK >= SND.UNA) or > [4] (SEG.SEQ = SND.WU.SEQ and SEG.ACK = SND.UNA and SEG.WND > SND.WND) > > SND.WND <- SEG.WND > [5] SEG.SEQ > SND.WU.SEQ > SND.WU.SEQ <- SEG.SEQ > [6] (SND.WU.ACK <- SEG.ACK) > > [1] If either timestamp is newer than what we've already seen this > is a new segment and the window it contains is certain to be valid > without any further checks. > [2] This is reliable indicator of a genuine window update. With the > arrival of new data that is ack'ed the window also has been updated. > [3] A higher sequence number tells us new data was received but if > the ACK is lower than what we've already seen it must be a retransmit. > [4] A pure window update if the sequence number is the same, the ACK is > not lower than what we've already seen and the advertised window is > larger than the one we had. > [5] Only change the last update that gave us a window update if it is > higher than what we have. This prevents retransmitted or reordered > segments without a new ACK from updating our window. With timestamps > we can reliably differentiate retransmits from out-of order segments. > [6] Tracking the last ACK that updated the window has become unnecessary. > SND.WU.ACK is also known as SND.WL2. > > Cases: > > o In unidirectional send we trigger always on [2] when our data is ack'ed. > o In unidirectional receive we trigger on [3] for in-order segments. Out > of order segments do not update the window unless they advance SND.WU.SEQ. > Retransmits are not detected unless timestamps are enabled. In that case > [1] triggers if the RTT is larger than the resolution of the timestamp > clock. Otherwise window updates will resume when all missing segments > are retransmitted and new segments beyond SND.WU.SEQ arrive. > o In bidirectional traffic we trigger on [3] and [2]. If the transfer has > loss or is re-ordered in either or both directions we also trigger in all > important cases due to [2] when new data was ack'ed, and [3] new data with > an up to date ACK is received. Above all the timestamp check allows all > new segments no matter what order they are in. > > > Feedback and pointing out of mistakes are welcome. > > BTW: TAC's are gone for good! > > -- > Andre > > andre@FreeBSD.org > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jun 24 08:09:57 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E393A69FD; Tue, 24 Jun 2008 08:09:57 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 089BF3A69FD for ; Tue, 24 Jun 2008 08:09:56 -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 uqh4WrsJgp31 for ; Tue, 24 Jun 2008 08:09:50 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id A8CCE3A6821 for ; Tue, 24 Jun 2008 08:09:50 -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 22083328539; Tue, 24 Jun 2008 10:09:51 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m5OF9pdl015739; Tue, 24 Jun 2008 10:09:51 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 10:09:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 10:09:49 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCPM agenda slots for Dublin Thread-Index: AcjWDFi1wilxOFldStKPaQ4rpNDMcw== From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 24 Jun 2008 15:09:51.0066 (UTC) FILETIME=[59909BA0:01C8D60C] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7160:2.4.4, 1.2.40, 4.0.166 definitions=2008-06-24_07:2008-06-24, 2008-06-24, 2008-06-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0805090000 definitions=main-0806240064 Cc: David Borman Subject: [tcpm] TCPM agenda slots for Dublin 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org We're in the process of planning the agenda for the TCPM meeting in Dublin. If you'd like to request a presentation slot, please let Dave and I know in the next couple weeks. Tell us: (1) What the topic is (and if it corresponds to a draft) (2) Who will present (3) How much time is requested The IETF meeting agenda currently has TCPM as a 2 hour timeslot on Monday evening from 17:40 - 19:50 (Dublin time), July 28th: https://datatracker.ietf.org/meeting/72/agenda.html Thanks. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 30 10:51:46 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16023A6AEA; Mon, 30 Jun 2008 10:51:46 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 1EFD73A6A1F; Mon, 30 Jun 2008 10:51:43 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080630175144.1EFD73A6A1F@core3.amsl.com> Date: Mon, 30 Jun 2008 10:51:44 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's Reaction to Soft Errors) to Informational 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP's Reaction to Soft Errors ' as an Informational 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 2008-07-14. 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-tcp-soft-errors-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14290&rfc_flag=0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 30 22:40:59 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518123A691D; Mon, 30 Jun 2008 22:40:59 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDD623A691D for ; Mon, 30 Jun 2008 22:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.837 X-Spam-Level: X-Spam-Status: No, score=-4.837 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_SUBJECT=1.762, 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 8JvSHDCrENmr for ; Mon, 30 Jun 2008 22:40:57 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D31843A67D7 for ; Mon, 30 Jun 2008 22:40:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,730,1204531200"; d="scan'208";a="61680619" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 30 Jun 2008 22:41:09 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m615f9XM006880; Mon, 30 Jun 2008 22:41:09 -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 m615f96I028723; Tue, 1 Jul 2008 05:41:09 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); Mon, 30 Jun 2008 22:41:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Jun 2008 22:40:08 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58056ADBF7@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcjbPOw31GAccW+CR1uFnpdk6j4Mxg== From: "Anantha Ramaiah (ananth)" To: "TCP Maintenance and Minor Extensions WG" X-OriginalArrivalTime: 01 Jul 2008 05:41:08.0981 (UTC) FILETIME=[101BE250:01C8DB3D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=751; t=1214890869; x=1215754869; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20 |Sender:=20; bh=bmueIPxoQ2K6lovrrhjnMj4+ZMH3IFpkpeSy60RjdO4=; b=lb0KGZR3SsjcZ6obwiO1xva9rWWUkhx4Ff8jPZ66SDegFiNjBPld6+f7LX u9niAPrzdKsnkEP+9QM1ue/jymyhL1GsFBd4ihNdFN+t5UJFHxeRK1DhsJ8x RVsPQfKRGV; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: David Borman , weddy@grc.nasa.gov Subject: [tcpm] (no subject) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi, The persist state issue draft [http://tools.ietf.org/html/draft-mahesh-persist-timeout-02], which was discussed in the mailing list last year, is now re-written into 2 separate drafts, the first one which clarifies the RFC 1122 verbiage surrounding the zero window probes and the second one which talks about the solutions in detail. This was done in response to the WG suggestions (which included David Borman and Mark Allman). You can find the copy of the first draft at : http://www.ietf.org/internet-drafts/draft-ananth-tcpm-persist-00.txt. Comments welcome. The second draft which is also informational, talks about the possible mitigations to the persist condition and will be posted at a later time. Thanks, -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 30 22:45:54 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72DEB3A6B23; Mon, 30 Jun 2008 22:45:54 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F3CF3A67D7 for ; Mon, 30 Jun 2008 22:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=0.881, 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 bq86d22vwP5G for ; Mon, 30 Jun 2008 22:45:52 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6E2793A6782 for ; Mon, 30 Jun 2008 22:45:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,730,1204531200"; d="scan'208";a="120766277" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Jun 2008 22:45:56 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m615jumW011962; Mon, 30 Jun 2008 22:45:56 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m615juTG012966; Tue, 1 Jul 2008 05:45:56 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 22:45:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Jun 2008 22:44:56 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58056ADBFB@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58056ADBF7@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP persist state issue. Thread-Index: AcjbPOw31GAccW+CR1uFnpdk6j4MxgAAB4TA References: <0C53DCFB700D144284A584F54711EC58056ADBF7@xmb-sjc-21c.amer.cisco.com> From: "Anantha Ramaiah (ananth)" To: "TCP Maintenance and Minor Extensions WG" X-OriginalArrivalTime: 01 Jul 2008 05:45:56.0126 (UTC) FILETIME=[BB42BBE0:01C8DB3D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1365; t=1214891156; x=1215755156; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20TCP=20persist=20state=20issue. |Sender:=20; bh=UZD8lEvU5cCkYuEQj9dnbj4j3MN/zzUatBAdFjWUVAM=; b=oIyN3ynw/khsOuzcmnVeWFhkjG6Ew6TJ71Hf7bANz0dNCUlN8FgNuUJ69i aGouh5EwLVZJxM1STxBb9ClV5ZJ54aPlYKRxNuudCkEx9zdgm41dJIuUhMFs rQGqsqIORk; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: weddy@grc.nasa.gov, David Borman Subject: [tcpm] TCP persist state issue. 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Typed too fast, this time adding the subject line. Sorry about that. Thanks, -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Anantha Ramaiah (ananth) > Sent: Monday, June 30, 2008 10:40 PM > To: TCP Maintenance and Minor Extensions WG > Cc: David Borman; weddy@grc.nasa.gov > Subject: [tcpm] (no subject) > > Hi, > > The persist state issue draft > [http://tools.ietf.org/html/draft-mahesh-persist-timeout-02], > which was discussed in the mailing list last year, is now > re-written into 2 separate drafts, the first one which > clarifies the RFC 1122 verbiage surrounding the zero window > probes and the second one which talks about the solutions in > detail. This was done in response to the WG suggestions > (which included David Borman and Mark Allman). > > You can find the copy of the first draft at : > http://www.ietf.org/internet-drafts/draft-ananth-tcpm-persist-00.txt. > Comments welcome. > > The second draft which is also informational, talks about the > possible mitigations to the persist condition and will be > posted at a later time. > > Thanks, > -Anantha > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm