From tcpm-bounces@ietf.org Wed Mar 5 18:42:53 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B1E28C1B2; Wed, 5 Mar 2008 18:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.397 X-Spam-Level: X-Spam-Status: No, score=-100.397 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 XBG2d3dNuGBN; Wed, 5 Mar 2008 18:42:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8276B28C1E1; Wed, 5 Mar 2008 18:42:52 -0800 (PST) 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 8A18F3A69FF for ; Wed, 5 Mar 2008 18:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 2K34WRt9yaD2 for ; Wed, 5 Mar 2008 18:42:49 -0800 (PST) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.69]) by core3.amsl.com (Postfix) with ESMTP id 9CBFB3A686F for ; Wed, 5 Mar 2008 18:42:49 -0800 (PST) Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout006/MantshX 4.0) with ESMTP id m262gdFC003913; Wed, 5 Mar 2008 18:42:39 -0800 (PST) Received: from [192.168.1.85] (adsl-70-132-4-244.dsl.snfc21.sbcglobal.net [70.132.4.244]) (authenticated bits=0) by mac.com (Xserve/asmtp005/MantshX 4.0) with ESMTP id m262gaTh027238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Mar 2008 18:42:37 -0800 (PST) Message-Id: From: Sally Floyd To: Stefanos Harhalakis In-Reply-To: <200802212353.09084.v13@v13.gr> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 5 Mar 2008 18:42:37 -0800 References: <200802200116.26451.v13@v13.gr> <200802212353.09084.v13@v13.gr> X-Mailer: Apple Mail (2.919.2) Cc: akuzma@northwestern.edu, tcpm@ietf.org Subject: Re: [tcpm] ECN+SYN 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-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 On Feb 21, 2008, at 1:53 PM, Stefanos Harhalakis wrote: > On Thursday 21 February 2008, Sally Floyd wrote: >> In summary, I would be *strongly* opposed to any proposal >> for TCP SYN packets to be sent as ECN-capable. > > Hello Sally and thank you for your detailed and explanatory reply! ... > I suggest that the draft: > a) Do not forbid ECT for SYN segments > b) Propose the usage of ECT for SYN segments I am sorry, but I would still be strongly opposed to this. > Since on an ECN enabled Internet that uses AQM everywhere the ECN > bits in IP > will (most probably) also work as a kind of QoS, we should not > consider ECT > only as a congestion indication method. We should have in mind the > effects of > not using ECT which will result in poorer performance. I totally > agree that > most probably we will not benefit from congestion indication in SYN > segments > and I understand that RFC3168 explicitly says that "an ECT codepoint > MUST NOT > be set in a packet unless the loss of that packet in the network > would be > detected by the end nodes and interpreted as an indication of > congestion" > (RFC3168 5.2) but on the other hand, SYN and SYN/ACK segments are > not exactly > data (for normal operations) and (I believe that) they are only a > very small > fraction of the whole internet traffic (either as packet count or byte > count). (1) The current Internet is not ECN-enabled. In particular, most TCP end nodes today are not using ECN. If a new protocol was proposed that was ECN-capable from day one, I think it would be fine for SYN packets in this new protocol to be sent as ECN-Capable. (Because there wouldn't be any backwards-compatibility problems with receivers from that protocol that didn't agree to use ECN.) This is not the case with TCP, however. (2) SYN packets can in fact be a factor in congestion (e.g., consider SYN floods). (3) If all SYN packets were sent as ECN-Capable, and routers marked rather than dropped these SYN packets in times of congestion, and the ECN mark was ignored by the TCP responder (because the TCP responder was not using ECN), this could significantly increase the level of congestion. Even if the SYN packets themselves weren't a significant part of the load. ... > Hope that this clarifies my thoughts... and that they are not > (totally) > wrong :-) - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Mar 9 12:24:01 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F013A6B7A; Sun, 9 Mar 2008 12:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 usp7YNjq0TTX; Sun, 9 Mar 2008 12:24:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1EA83A6942; Sun, 9 Mar 2008 12:24:00 -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 2A1E43A68DC for ; Sun, 9 Mar 2008 12:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 9To1G0vN9XLB for ; Sun, 9 Mar 2008 12:23:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A5C173A6A79 for ; Sun, 9 Mar 2008 12:23:57 -0700 (PDT) Received: from [67.59.55.189] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JYR5R-0008vY-7j for tcpm@ietf.org; Sun, 09 Mar 2008 19:21:35 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id A2D722BE21 for ; Sun, 9 Mar 2008 15:21:31 -0400 (EDT) Received: by colt.internal (Postfix, from userid 3000) id 66909285BD; Sun, 9 Mar 2008 15:21:31 -0400 (EDT) Date: Sun, 9 Mar 2008 15:21:31 -0400 From: Ethan Blanton To: tcpm@ietf.org Message-ID: <20080309192131.GA7052@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org MIME-Version: 1.0 X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.13 (2006-08-11) Subject: [tcpm] RFC 2581 bis draft update 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-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0145598792==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0145598792== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline --A6N2fC+uXW/VQSAv Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi folks, We missed the IETF cutoff, but a new revision of 2581bis is available for review. We believe that it addresses the remaining comments from WGLC, and would appreciate if people could look it over. In order to ease review, please find attached a summary of the major comments and corresponding changes which went into this revision. A copy of the draft is available at: http://www.cs.purdue.edu/homes/eblanton/ietf/draft-ietf-tcpm-rfc2581bis-04a.txt Thanks, Ethan --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename=file Content-Transfer-Encoding: quoted-printable Alfred H=F6nes: Clarify Section 6, with respect to language unchaned from 2581 which uses phrases like "this document" where it should say "[RFC2581]", etc. Done. Gorry Fairhurst: I think the document should also refer to PLPMTUD as a valid IETF-specified way to choose a segment size. Section 2, the definition of SMSS now references RFC 4821. The wording in the draft is not clear whether [RMSS] is an upper bound to the SMSS, or just one of many ways to discover a sensible SMSS. The wording of 2581bis is taken directly from RFC 2581. It is not clear, but changing it to be stricter seems to be a change in behavior, and the looser interpretation (that it is merely a way to discover a sensible SMSS) seems to be allowed by the current text. Gorry agrees. Is the default RMSS still 536 bytes also for IPv6, since [RFC1122] does not apply in this context to IPv6. Further iteration with Gorry indicated that the existing text is probably okay; changes may be needed to other documents. The document speaks only of loss, but I'm assuming that this applies equally to ECN. If that is so, perhaps we should explicitly say so up-front. Section 3 has been clarified to explicitly note RFC 3168. Markku Kojo: Looking into the Linux TCP behavior (that differs from what the draft specifies) seems to reveal an issue with the draft in its usage of FlightSize as a bad estimate for the amount of outstanding data in the *network* and consequently inappropriate adjustment of ssthresh (and cwnd). That is, replacing cwnd with FlightSize in equation 4 seem to have resulted in similar kind of problems as there were earlier when cwnd was used in the equation: [FlightSize is inflated]. Step 2 in Section 3.2 has been modified to include the following text: When [RFC3042] is in use, additional data sent in limited transmit MUST NOT be included in this calculation. Algorithmic solutions to the problem require an additional state variable in the algorithms as defined. Rather than forge down this route, we choose to make implementors aware of the problem and let them deal with it as they see fit. Note that this problem may be a non-issue on some stacks (particularly those using RFC 3517 or similar). It might be useful also note that the purpose of the slow start algorithm is to (re)start the ack clock (in addition to determining the available capacity). Done. "On the other hand, when a TCP sender detects segment loss using = =20 the retransmission timer and the given segment has already been retransmitted at least once, the value of ssthresh is held constant." = =20 Should be clarified that this applies only when the retransmission timer expires again for the same segment, not when retransmission timer expires for a fast retransmitted segment. Done. It would be useful to note that allowing a TCP sender to send a new data segment on the 1st and 2nd dupack is in violation to the definition of cwnd in Section 2[.] No change. While this is true, the text is pretty clear about exactly what you do, and when. "Loss in two successive windows of data, or the loss of a = =20 retransmission, should be taken as two indications of congestion and, therefore, cwnd (and ssthresh) MUST be lowered twice in this case." = =20 Lowering ssthresh twice on the loss of a retransmission triggered by an RTO would be in contradiction with what is said in Section 3.1 (see item 2 above). Should clarify that this is valid only with the loss of a fast retransmit (or the loss of a retransmission in fast recovery with an advanced loss recovery alg such as NewReno or SACK-based fast recovery) With the clarification above, this is no longer necessary. --r5Pyd7+fXNt84Ff3-- --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH1Di7r9kA9Ig8HBQRAurSAJ94Ye7181i4iVbiD9TOb5f5Epc2LQCdFmIT NBpvckzmzmv5bYh6upFMU8g= =Nwwh -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv-- --===============0145598792== 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 --===============0145598792==-- From tcpm-bounces@ietf.org Mon Mar 10 10:17:30 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB1F3A7020; Mon, 10 Mar 2008 10:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.917 X-Spam-Level: X-Spam-Status: No, score=-104.917 tagged_above=-999 required=5 tests=[AWL=-5.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 zhFK725y2DX6; Mon, 10 Mar 2008 10:17:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7649728C403; Mon, 10 Mar 2008 10:12:34 -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 59A9928C402 for ; Mon, 10 Mar 2008 10:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 Mr6s8CRmx-QB for ; Mon, 10 Mar 2008 10:12:24 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 8C45428C467 for ; Mon, 10 Mar 2008 10:08:30 -0700 (PDT) Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.54.46.188) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 10 Mar 2008 10:06:15 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.54.46.188]) with mapi; Mon, 10 Mar 2008 10:05:49 -0700 From: Murari Sridharan To: "tcpm@ietf.org" , "pasi.sarolahti@nokia.com" , "mallman@icir.org" Date: Mon, 10 Mar 2008 10:05:46 -0700 Thread-Topic: F-RTO and RFC 3517 interaction issues Thread-Index: AciC0PuvPI3Il/LvTdqfSHmLW8eJPA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [tcpm] F-RTO and RFC 3517 interaction issues 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-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0821736021==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0821736021== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_FCA794787FDE0D4DBE9FFA11053ECEB60C7947458ENAEXMSGC110re_" --_000_FCA794787FDE0D4DBE9FFA11053ECEB60C7947458ENAEXMSGC110re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am seeing an inconsistency between FRTO and RFC 3517. May be the authors = could clarify. F-RTO defines recovery as follows Set variable "recover" to indicate the highest segment transmitted so far. RFC 3517 defines "HighData" is the highest sequence number transmitted at a given point. RFC 3517 clearly mandates that if RTO occurs during loss recovery new recov= ery phase MUST not be initiated until the RecoveryPoint is crossed. "If an RTO occurs during loss recovery as specified in this document, RecoveryPoint MUST be set to HighData. Further, the new value of RecoveryPoint MUST be preserved and the loss recovery algorithm outlined in this document MUST be terminated. In addition, a new recovery phase (as described in section 5) MUST NOT be initiated until HighACK is greater than or equal to the new value of RecoveryPoint." Now FRTO spec seems to violate the above rule with the following statement If the algorithm exits with SpuriousRecovery set to SPUR_TO, "recover" is set to SND.UNA, thus allowing fast recovery on incoming duplicate acknowledgments. This means that if we are in the middle of loss recovery and a real timeout= occurs we save the recovery point per RFC 3517. At this point we continue = with slow start and congestion avoidance, now say we are still below the ea= rlier recovery point and a new timeout occurs. This time if the timeout is = classified as SPUR_TO, then RecoveryPoint is set to SndUNA, overwriting the= older value and a new recovery phase can begin, clearly violating RFC 3517= . Thanks Murari --_000_FCA794787FDE0D4DBE9FFA11053ECEB60C7947458ENAEXMSGC110re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am seeing an inconsistency between FRTO and RFC 3517= . May be the authors could clarify.

 

F-RTO defines recovery as follows

 

Set variable "recover" to

      indicate the highest segment transmitted so far.

 

RFC 3517 defines 

"HighData" is the highest sequence number transmitted at a g=
iven
      point.<=
/pre>


 



RFC 3517 clearly mandates that if RTO occurs during lo=
ss
recovery new recovery phase MUST not be initiated until the RecoveryPoint i=
s
crossed. 



“If an RTO occurs during loss recovery as specified in this docu=
ment,
   RecoveryPoint MUST be set to HighDa=
ta.  Further, the new value of
   Recov=
eryPoint MUST be preserved and the loss recovery algorithm
=

   outlined in this document MUST be terminated.  In ad=
dition, a new
   recovery phase (as describe=
d in section 5) MUST NOT be initiated
   unt=
il HighACK is greater than or equal to the new value of
   RecoveryPoint.”
 =

 
Now FRTO spec seems to violate the a=
bove rule with the following statement
If the algorith=
m exits with
   SpuriousRecovery set to SPUR=
_TO, "recover" is set to SND.UNA, thus
 =
;  allowing fast recovery on incoming duplicate acknowledgments.<=
/o:p>
 
This means that if we are in th=
e middle of loss recovery and a real timeout occurs we save the recovery po=
int per RFC 3517. At this point we continue with slow start and congestion =
avoidance, now say we are still below the earlier recovery point and a new =
timeout occurs. This time if the timeout is classified as SPUR_TO, then Rec=
overyPoint is set to SndUNA, overwriting the older value and a new recovery=
 phase can begin, clearly violating RFC 3517. 
&n=
bsp;
Thanks
Murari
--_000_FCA794787FDE0D4DBE9FFA11053ECEB60C7947458ENAEXMSGC110re_-- --===============0821736021== 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 --===============0821736021==-- From tcpm-bounces@ietf.org Mon Mar 10 16:35:28 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52BF53A67B6; Mon, 10 Mar 2008 16:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.445 X-Spam-Level: X-Spam-Status: No, score=-99.445 tagged_above=-999 required=5 tests=[AWL=0.992, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 hWWSiCLIhiPM; Mon, 10 Mar 2008 16:35:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289433A6879; Mon, 10 Mar 2008 16:35:27 -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 130DA3A6879 for ; Mon, 10 Mar 2008 16:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 jvznfbKFwcTh for ; Mon, 10 Mar 2008 16:35:24 -0700 (PDT) Received: from kilo.rtfm.com (unknown [130.129.87.199]) by core3.amsl.com (Postfix) with ESMTP id D64133A67B6 for ; Mon, 10 Mar 2008 16:35:24 -0700 (PDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 47E9B1AA4C7; Mon, 10 Mar 2008 19:33:04 -0400 (EDT) Date: Mon, 10 Mar 2008 19:33:04 -0400 From: Eric Rescorla To: tcpm@ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> Cc: saag@mit.edu Subject: [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00 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-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 started writing comments on this and after I'd spent about 2 hours writing background material, I decided to cram it into an I-D. Until it appears on the I-D directory, you can find it at: https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tcp-auth-arch.txt Anyway, review follows: $Id: draft-ietf-tcpm-tcp-auth-opt-00-rev.txt,v 1.2 2008/03/10 23:11:21 ekr Exp $ GENERAL COMMENTS I'm not convinced it's necessary to have a new key for each connection. This is primarily useful to prevent inter-connection cut-and-paste attacks, and it's not clear how serious those are. I think it's particularly problematic to levy this requirement without providing some mechanism for arranging that, since that basically implies having some automatic mechanism for establishing fresh per-connection keys, which doesn't currently exist. That makes this mechanism distinctly less useful than RFC 2385. I don't think this API, specification of the TSAD, etc., is particularly helpful. IPsec needed the concept of an association database because packets corresponding to multiple associations got similar treatment. However, TCP has an explicit notion of connection so it would be far more convenient to simply refer to keys as tied to connections, and then have a set of rules for mapping which connections get which keys. Even if some TSAD-type abstraction is useful, I don't think it's appropriate to define things like the size of each parameter in the TSAD as opposed to on the wire, or to describe the default values of various parameters as in S 3. For instance: iii. Key length. A byte indicating the length of the connection key in bytes. Those are internal implementation issues. Certainly, I might want to use a native int in my implementation. Why should this document tell me otherwise? TECHNICAL COMMENTS S 1.1. I don't see a lot of value in pre-specifying two MAC algorithms as MTI. There's no reason to believe one isn't plenty, as used in other protocols. S 2.2. This thing with the key-id being present if the MAC is odd, but absent if it's even strikes me as being overly clever. Let's just burn an octet on key-id and leave it at that. S 3. >> At least one direction (inbound/outbound) SHOULD have a non-NONE MAC in practice, but this MUST NOT be strictly required by an implementation. 1. This seems like a bad idea. It's very hard to analyze the security properties of a connection when only one side is protected. To take one case that is obviously bad, if you're worried about DoS attacks and you use TCP-AO, then forging packets in either direction can bring it down. I would reverse this and require MACs in both directions. 2. Even if we stipulate that this might be an OK idea, it's not appropriate to require implementations to support it. S 4.1. >> New TSAD entries MUST be checked against a table of previously used TSAD entries, and key reuse MUST be prohibited. Huh? So, I have to keep a list of every TSAD entry ever and check against the table. Seems better to just to do this by construction. S 4.3. >> TCP segments with TCP-AO but not matching TSAD entries MUST be silently accepted; this is required for equivalent function with TCPs not implementing TCP-AO. I don't see this. Can you explain? >> Silent discard events SHOULD be signaled to the user as a warning, and silent accept events MAY be signaled to the user as a warning. I don't really understand what a warning means here? syslog? S 5. Implementations are encouraged to keep keys in a suitably private area. Users of TCP-AO are encouraged to use different keys for inbound and outbound MACs on a given TCP connection. Some discussion of why different keys are good or bad would help here. As far as I can tell, reflection attacks aren't an issue as long as the host/port quartet is incuded in the header. S 5.1. o Number of bytes to be sent/received (two bytes); this is used on the send side to trigger bytecount-based KeyID changes, and on the receive side only for statistics or length-sensitive KeyID selection. Please explain the cryptographic rationale for why you would want to do bytecount based key changes. S 9. TCP-AO does not expose the MAC algorithm used to authenticate a particular connection; that information is kept in the TSAD at the endpoints, and is not indicated in the header. This seems to be of extremely marginal security benefit. There are likely to be <5 algorithms in use. So, searching all of them increases the effective key size by <3 bits. EDITORIAL COMMENTS S 1. there have been escalating attacks on the algorithm itself [Be05] [Bu06]. TCP MD5 also lacks both key management and algorithm These citations should be to the original papers, not the summaries (not that I mind you citing Steve's and my paper...) o S 2.2. Figure 2 is kind of hard to read since the length of the kind field is 16 bits, but kinds are 8 bits, rigth? S 3. Note that the connection key is not included here; we expect that the MAC algorithm will indicate how to use the key, e.g., as HMACs do in s/HMACs do/HMAC does/ TCP-AO by default includes the TCP options because these options are intended to be end-to-end and some are required for proper TCP operation (e.g., SACK, timestamp, large windows). Middleboxes that I dpn't understand what "by default" means here. This needs to be configured on both sides, right? So, this is just a UI issue. S 5. the default case. Segments carry only enough context to identify the security association [RFC4301][RFC4306]. In TCP-AO, this context is I'm not sure what security association means here. You're not using IKE, right? S 9. TCP-AO does not expose the MAC algorithm used to authenticate a particular connection; that information is kept in the TSAD at the endpoints, and is not indicated in the header. I may not be enough of a TCP wonk, but what's a connection ID? -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Mar 10 17:11:01 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173F428C247; Mon, 10 Mar 2008 17:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.628 X-Spam-Level: X-Spam-Status: No, score=-100.628 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 alT4OXmKC0Jd; Mon, 10 Mar 2008 17:11:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1853928C1C4; Mon, 10 Mar 2008 17:11:00 -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 A85073A6998 for ; Mon, 10 Mar 2008 17:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 UQXln5WpfGUd for ; Mon, 10 Mar 2008 17:10:56 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0DC3C3A67F9 for ; Mon, 10 Mar 2008 17:10:55 -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 m2B08Qvv012248; Tue, 11 Mar 2008 02:08:30 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 02:08:29 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 02:08:29 +0200 Received: from [130.129.17.79] ([10.241.59.4]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 02:08:29 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <7D419A49-15F9-450F-B51B-C217123475F7@nokia.com> From: Pasi Sarolahti Date: Mon, 10 Mar 2008 20:08:26 -0400 To: ext Murari Sridharan X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 11 Mar 2008 00:08:29.0388 (UTC) FILETIME=[08FFB0C0:01C8830C] X-Nokia-AV: Clean Cc: "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] F-RTO and RFC 3517 interaction issues 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi Murari, Thanks for the careful reading! Clarification might indeed be in place. From quite early on when specifying the F-RTO algorithm we have = thought it would be ok to allow fast recovery/SACK recovery = immediately after detected spurious timeout, because then the TCP = sender does not send the RTO retransmissions, and therefore the = potential for RTO retransmissions triggering multiple fast = retransmits should not exist (so the recover variable can be reset). = For a case where spurious retransmission timeout follows the SACK = recovery or fast recovery directly, this reasoning should be valid, = do we agree? In case where spurious timeout happens during an earlier RTO = recovery, there could be potential for false fast retransmits to = happen, as described in the original NewReno draft. (RFC 3517 does = not describe it in such detail, but I assume the motivation for the = text you quote is same also there). On the other hand, the draft says = that F-RTO SHOULD NOT be applied when an earlier SACK recovery is in = progress, as I think it was in the example you presented. Do you = think this note is sufficient, or should it be clarified somehow? - Pasi On Mar 10, 2008, at 13:05, ext Murari Sridharan wrote: > I am seeing an inconsistency between FRTO and RFC 3517. May be the = > authors could clarify. > > F-RTO defines recovery as follows > > Set variable "recover" to > indicate the highest segment transmitted so far. > > RFC 3517 defines > "HighData" is the highest sequence number transmitted at a = > given point. > > RFC 3517 clearly mandates that if RTO occurs during loss recovery = > new recovery phase MUST not be initiated until the RecoveryPoint is = > crossed. > =93If an RTO occurs during loss recovery as specified in this = > document, RecoveryPoint MUST be set to HighData. Further, the = > new value of RecoveryPoint MUST be preserved and the loss = > recovery algorithm outlined in this document MUST be terminated. = > In addition, a new recovery phase (as described in section 5) = > MUST NOT be initiated until HighACK is greater than or equal to = > the new value of RecoveryPoint.=94 Now FRTO spec seems to violate = > the above rule with the following statementIf the algorithm exits = > with SpuriousRecovery set to SPUR_TO, "recover" is set to = > SND.UNA, thus allowing fast recovery on incoming duplicate = > acknowledgments. This means that if we are in the middle of loss = > recovery and a real timeout occurs we save the recovery point per = > RFC 3517. At this point we continue with slow start and congestion = > avoidance, now say we are still below the earlier recovery point = > and a new timeout occurs. This time if the timeout is classified as = > SPUR_TO, then RecoveryPoint is set to SndUNA, overwriting the older = > value and a new recovery phase can begin, clearly violating RFC = > 3517. ThanksMurari _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Mar 10 17:16:29 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2910A3A6998; Mon, 10 Mar 2008 17:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.378 X-Spam-Level: X-Spam-Status: No, score=-100.378 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 iLTBuuopMy+T; Mon, 10 Mar 2008 17:16:28 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571243A69CD; Mon, 10 Mar 2008 17:16: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 751623A6BDC for ; Mon, 10 Mar 2008 17:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 jS0HeIu2XYbg for ; Mon, 10 Mar 2008 17:16:26 -0700 (PDT) Received: from mx-out-05.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id 5A1733A6998 for ; Mon, 10 Mar 2008 17:16:25 -0700 (PDT) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.13.8/8.13.8) with ESMTP id m2B0E4jY013098 for ; Tue, 11 Mar 2008 02:14:04 +0200 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.32]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id m2B0E46v023952 for ; Tue, 11 Mar 2008 02:14:04 +0200 Received: from hell.hell.gr (adsl6-211.lsf.forthnet.gr [79.103.133.211]) by MX-IN-05.forthnet.gr (8.14.2/8.14.2) with ESMTP id m2B0DxZZ026089 for ; Tue, 11 Mar 2008 02:14:00 +0200 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-05.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: tcpm@ietf.org User-Agent: KMail/1.9.7 References: <200802200116.26451.v13@v13.gr> <200802212353.09084.v13@v13.gr> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Date: Tue, 11 Mar 2008 02:12:46 +0200 Message-Id: <200803110212.46979.v13@v13.gr> Subject: Re: [tcpm] ECN+SYN 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-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 On Thursday 06 March 2008, Sally Floyd wrote: > On Feb 21, 2008, at 1:53 PM, Stefanos Harhalakis wrote: > > On Thursday 21 February 2008, Sally Floyd wrote: > >> In summary, I would be *strongly* opposed to any proposal > >> for TCP SYN packets to be sent as ECN-capable. > > > > Hello Sally and thank you for your detailed and explanatory reply! > > ... > > > I suggest that the draft: > > a) Do not forbid ECT for SYN segments > > b) Propose the usage of ECT for SYN segments > > I am sorry, but I would still be strongly opposed to this. Hello again, I respect your experience and I blindly accept your opinion (re: the draft) since is most probably based on greater knowledge than mine. I'm also very stubborn and reserve the right to research this a bit more and either prove myself wrong or come back with more solid arguments :-) Either way, I'll keep the list (tcpm) informed. Thank you for your time, Harhalakis Stefanos _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Mar 10 18:33:45 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7653A69F9; Mon, 10 Mar 2008 18:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Xam3DumnuiUS; Mon, 10 Mar 2008 18:33:43 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22E23A6851; Mon, 10 Mar 2008 18:33:43 -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 A32533A6851 for ; Mon, 10 Mar 2008 18:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 q8f4Fyj1APsL for ; Mon, 10 Mar 2008 18:33:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3B0BD3A67EF for ; Mon, 10 Mar 2008 18:33:42 -0700 (PDT) Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2B1UlLU015902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Mar 2008 18:30:50 -0700 (PDT) Message-ID: <47D5E09A.5000803@isi.edu> Date: Mon, 10 Mar 2008 18:30:02 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla , IETF Security Area WG , tcpm@ietf.org X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] discussion of draft-rescorla-tcp-auth-arch-00.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-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1915224238==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1915224238== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig591A580DD43B812CE3076EB4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig591A580DD43B812CE3076EB4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Eric, Again, thanks for the detailed comments. Discussion below... This too should be useful to discuss further in TCPM. Joe > Network Working Group E. Rescorl= a > Internet-Draft RTFM, Inc= =2E > Intended status: Informational March 09, 200= 8 > Expires: September 10, 2008 >=20 >=20 > Notes on TCP Authentication Architectures > draft-rescorla-tcp-auth-arch-00.txt =2E.. > 1. Introduction =2E.. > Note that there is currently two documents > [I-D.ietf-tcpm-tcp-auth-opt] [I-D.bellovin-tcpsec] that discuss > additional requirements, but it's not clear to me that these > requirements have consensus or in fact are correct. The documents were presented at the last IETF, where we solicited=20 comments on those requirements. The requirements were presented as=20 having the consensus of the TCP-AO design team only at that time. =2E.. > 3. Keys and Associations >=20 > Probably the most important architectural question is the > relationship of keys to associations. As indicated above, TCP MD5 > uses a single static key for all associations. This key is > configured in a pairwise fashion. By contrast, conventional channel= > security protocols such as TLS [RFC4346] or IPsec [RFC4301] establis= h > a fresh set of keying material for each association. The proposed > TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] also requires= > (though does not arrange for) a fresh key for each association. TCP-AO is identical to IPsec [i.e., 4301] in that regard; neither=20 arranges for keys, and both rely on a separate protocol to do so, in the = sense that IPsec relies on IKE. > >> New TSAD entries MUST be checked against a table of previously= > used TSAD entries, and key reuse MUST be prohibited. >=20 > There are two good (and one not so good) reasons why it's desirable > to have mechanisms for changing keys: Changing keys is not related to the above key reuse issue AFAICT. Key changes are to reduce the amount of material signed under a single=20 key, to reduce the utility of signed packets to a cryptoanalyst. Key reuse is critical to preventing replay attacks within a connection=20 ID (src IP, dst IP, src port, dst port, aka socket pair). It is useful=20 to avoid keying different ports or even different hosts with the same=20 key, but only in a general sense (i.e., to again reduce the amount of=20 material signed with a single key). > o To arrange for different cryptographic keying material to be used= > for each connection, thus preventing cut-and-paste attacks betwee= n > connections. (Good) Those don't seem relevant; the ports change, so the signatures would chan= ge. > o To allow rekeying in case of key compromise. (Good) Rekeying of a connection is not necessarily related to rekeying an=20 endpoint. Connection key compromise is not something we're designing to=20 address per se. > o To limit the amount of plaintext/MAC pairs available to the > attacker (Not-so-good) Is that the 'amount of keyed material' kind of stuff above? That was=20 given by Bellovin as an issue with TCP-MD5. > In TCP, cut-and-paste attacks are also possible within a connection > due to sequence number rollover. This can be fixed, however, by > extending the sequence numbers virtually, as done with ESP/AH. We definitely do not want to tie the keying directly to the sequence=20 space for a variety of reasons (we listed some, I believe); this is done = indirectly by bytecounts or packet counts to trigger key changes. > 4. Credentials Interface >=20 > As described at the beginning of this document, essentially all the > currently deployed systems use a single pre-configured pairwise > shared key. This key is directly configured on the router interface= =2E > For instance, here's the example from Cisco's IOS manuals [REF: htt= p > ://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/ > 1cbgp.html#wp5978] >=20 > router bgp 109 neighbor 145.2.2.2 password v61ne0qkel33& >=20 > It's extremely desirable to be able to retain the existing > interfaces. Any solution which requires a significant change to > those interfaces and especially to the interaction model creates a > substantial additional burden on operators, which creates a major > barrier to deployment. That would be allowed if the key management system used a single master=20 endpoint key, and derived connection keys from that key. I.e., if this=20 is critical to BGP, then BGP will require TCP-AO and a specific key=20 management protocol. Again, this isn't different from saying "IPsec with = IKE" at the IP layer, except that we are intending that TCP-AO and its=20 key management system are simpler to implement (partly because they're=20 specific to a single transport protocol). > 5. Handshake and Capabilities Discovery >=20 > The ability to automatically discover a peer's capabilitiies is a > common feature of modern cryptographic protocols. \ Like IPsec, we rely on the key management protocol to perform this. This = is not a part of TCP-AO as a result. > 6. Potential Architectures >=20 > This section describes a number of potential architectures for key > management for TCP. I'll skip them here, excepting ones that affect TCP-AO: > 6.2.1. Internal Key Management Protocol >=20 > The traditional approach to this problem would be to build a KMP int= o > TCP. This would presumably entail designing a new crypto protocol > (no small job) which is then carried in a TCP option. TCP option space is already consumed by a number of commonly used=20 options, and we want to retain space for additional options where=20 possible. Space is most limited in the SYN packet, which is where the=20 initial key exchange would occur. Because there isn't enough TCP option space for this sort of solution,=20 we excluded it as a possibility. =2E.. > 6.2.3. Layered KMP >=20 > Another way to provide a separate KMP is to bind it more tightly to > the transport protocol by running it over (or next to, as in DTLS- > SRTP [I-D.ietf-avt-dtls-srtp]) the transport protocol. At the time > that the association is created, the application initiating the > association also initiates a KMP exchange over (next to) the > transport protocol. When the KMP terminates, it outputs keying and > parameter information and imposes them on the association. In the > case of TLS over TCP, this would look something like: >=20 > TCP Client TCP Server > ---------- ---------- > TCP SYN -------------------------------------> > <---------------------------------- TCP SYN/ACK > TCP ACK -------------------------------------> > <--------- TLS Handshake (over TCP) ------> > Keys to TCP Keys to TCP= > App data (protected with TCP integrity) -----> > <----- App data (protected with TCP integrity) This fails to protect the SYN exchange, which we consider a requirement. = It also changes state from non-keyed to keyed; it would be very=20 difficult to introduce that sort of stateful change inside the TCP=20 protocol in ways that affect the data stream, since no other options=20 have that kind of effect (i.e., of affecting all data after some point). --- --------------enig591A580DD43B812CE3076EB4 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 iD8DBQFH1eCaE5f5cImnZrsRAtqKAKCkOpSWIcSR0yqtvqyNSEeif5nIPACgl5// grdeJWN5biUgovCo/MKyD00= =7rmx -----END PGP SIGNATURE----- --------------enig591A580DD43B812CE3076EB4-- --===============1915224238== 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 --===============1915224238==-- From tcpm-bounces@ietf.org Mon Mar 10 18:33:48 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FDDF3A6ADB; Mon, 10 Mar 2008 18:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 AwUWML66wro1; Mon, 10 Mar 2008 18:33:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83E63A68EC; Mon, 10 Mar 2008 18:33:46 -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 88C5E3A68EC for ; Mon, 10 Mar 2008 18:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ts7PBD+zZDfF for ; Mon, 10 Mar 2008 18:33:45 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1A1063A69F9 for ; Mon, 10 Mar 2008 18:33:45 -0700 (PDT) Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2B1UdSR015862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Mar 2008 18:30:42 -0700 (PDT) Message-ID: <47D5E090.9010608@isi.edu> Date: Mon, 10 Mar 2008 18:29:52 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> In-Reply-To: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: saag@mit.edu, tcpm@ietf.org Subject: Re: [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00 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-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1136996603==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1136996603== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE118A070FCD485B77E83166F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE118A070FCD485B77E83166F Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Eric, Thanks for the detailed comments. Some responses based on the text below. I'll comment on the ID separately... Also, I would expect that most of these issues would be useful to=20 discuss further in TCPM if you're available. Otherwise, we could meet=20 separately... Joe Eric Rescorla wrote: > I started writing comments on this and after I'd spent about=20 > 2 hours writing background material, I decided to cram it=20 > into an I-D. Until it appears on the I-D directory, you > can find it at: >=20 > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tcp-auth= -arch.txt >=20 > Anyway, review follows: >=20 > $Id: draft-ietf-tcpm-tcp-auth-opt-00-rev.txt,v 1.2 2008/03/10 23:11:21 = ekr Exp $ >=20 > GENERAL COMMENTS > I'm not convinced it's necessary to have a new key for each > connection. This is primarily useful to prevent inter-connection > cut-and-paste attacks, and it's not clear how serious those > are.=20 It's there primarily to prevent packets from an old version of a=20 connection from being used on a new connection, i.e., replay attacks=20 between a connection and its successor using the same port pair. I.e., IMO it's a MUST within a port pair for some period of time (the=20 cache check), and a SHOULD (for general security reasons) between port=20 pairs. The SHOULD can be dropped if (IMO) SAAG doesn't consider reusing=20 keys for different datasets an issue. > I think it's particularly problematic to levy this > requirement without providing some mechanism for arranging > that, since that basically implies having some automatic > mechanism for establishing fresh per-connection keys, which > doesn't currently exist. That makes this mechanism distinctly > less useful than RFC 2385. It does imply that for systems that re-establish connections frequently=20 either a a fresh key generation system is available, or a fairly long=20 list is preloaded. > I don't think this API, specification of the TSAD, etc., is > particularly helpful. IPsec needed the concept of an association > database because packets corresponding to multiple associations > got similar treatment. However, TCP has an explicit notion > of connection so it would be far more convenient to simply > refer to keys as tied to connections, and then have a set > of rules for mapping which connections get which keys. That's exactly what the TSAD is (or at least is supposed to be). It=20 might be useful to discuss this offline to figure out what the=20 disconnect is... > Even if some TSAD-type abstraction is useful, I don't think > it's appropriate to define things like the size of each > parameter in the TSAD as opposed to on the wire,=20 The TSAD API needs to be specified in detail because the key management=20 solution needs to rely on that information. > or to > describe the default values of various parameters as in > S 3. For instance: > > iii. Key length. A byte indicating the length of the=20 > connection key in bytes. =20 >=20 > Those are internal implementation issues. Certainly, I might > want to use a native int in my implementation. Why should > this document tell me otherwise? Again, it's to allow another party - the key management solution - to=20 load the TSAD. > TECHNICAL COMMENTS > S 1.1. > I don't see a lot of value in pre-specifying two MAC algorithms > as MTI. There's no reason to believe one isn't plenty, as used > in other protocols. >=20 > S 2.2. > This thing with the key-id being present if the MAC is odd, > but absent if it's even strikes me as being overly clever. > Let's just burn an octet on key-id and leave it at that. That would be discussed in TCPM further. The primary utility is for=20 short connections where the key isn't expected to need to rollover, and=20 where TCP option bytes are in extreme scarcity, esp. because single byte = can end up adding 4 overall, due to alignment issues. If that's not useful, we can decide to make the key-id always present. > S 3. > >> At least one direction (inbound/outbound) SHOULD have= =20 > a non-NONE MAC in practice, but this MUST NOT be strictl= y=20 > required by an implementation. =20 >=20 > 1. This seems like a bad idea. It's very hard to analyze the security > properties of a connection when only one side is protected. To take > one case that is obviously bad, if you're worried about DoS attacks > and you use TCP-AO, then forging packets in either direction can > bring it down. I would reverse this and require MACs in both directions= =2E For BGP, this is important. For servers, it's not necessarily feasible - = clients may authenticate the server, but the converse may not=20 necessarily be true. Yes, this allows attacks in one direction to=20 succeed, but it also isn't clear that both directions are equally=20 vulnerable, is it? > 2. Even if we stipulate that this might be an OK idea, it's not > appropriate to require implementations to support it. I'm not sure I understand this; if we say that connections MAY have=20 unidirectional auth, then it seems like the implementation MUST support=20 that capability. > S 4.1. > >> New TSAD entries MUST be checked against a table of previously=20 > used TSAD entries, and key reuse MUST be prohibited.=20 >=20 > Huh? So, I have to keep a list of every TSAD entry ever and check > against the table. Seems better to just to do this by construction. I'm not sure what "by construction" means, but that's certainly better=20 if possible. Can you suggest text or explain this off-line? > S 4.3. > >> TCP segments with TCP-AO but not matching TSAD entries MUST be=20 > silently accepted; this is required for equivalent function with TCP= s=20 > not implementing TCP-AO. =20 >=20 > I don't see this. Can you explain? TCP-AO is just a signature. If you don't have enough information to=20 invalidate the signature, you don't have enough reason to drop a segment.= The expected use case is that an endsystem will authenticate only a=20 subset of its connections; for those connections, it would install keys=20 - even if random ones - to "lock" those ports down. It's simpler to do=20 that than to lock everything by default and open things up explictly,=20 IMO, but we can default in either direction if necessary. Consider the case of a system that does not implement TCP-AO. TCP=20 ignores options it doesn't understand, so the connection will work fine. = Now you install TCP-AO, but don't load any keys. The intent is that an=20 un-keyed connection is the same as TCP without TCP-AO. > >> Silent discard events SHOULD be signaled to the user as a warning= ,=20 > and silent accept events MAY be signaled to the user as a warning.=20 >=20 > I don't really understand what a warning means here? syslog? That's one way. Others accumulate the info in a variable that apps can=20 check, e.g., via the socket interface. > S 5. > Implementations are encouraged to keep keys in a suitably private=20 > area. Users of TCP-AO are encouraged to use different keys for=20 > inbound and outbound MACs on a given TCP connection.=20 >=20 > Some discussion of why different keys are good or bad would help > here. As far as I can tell, reflection attacks aren't an issue > as long as the host/port quartet is incuded in the header. Sure. The goal is the general one of avoiding rekeying symmetric data=20 with the same key. It's not based on a specific kind of attack. > S 5.1. > o Number of bytes to be sent/received (two bytes); this is used on = > the send side to trigger bytecount-based KeyID changes, and on th= e=20 > receive side only for statistics or length-sensitive KeyID=20 > selection.=20 >=20 > Please explain the cryptographic rationale for why you would want to > do bytecount based key changes. That part of the API is strawman; we expect to need to count either=20 messages or bytes or both. If message counts are more useful, then we=20 can change to that. > S 9. > TCP-AO does not expose the MAC algorithm used to authenticate a=20 > particular connection; that information is kept in the TSAD at the=20 > endpoints, and is not indicated in the header.=20 >=20 > This seems to be of extremely marginal security benefit. There > are likely to be <5 algorithms in use. So, searching all of them > increases the effective key size by <3 bits.=20 The other reason to not include it is space; it's not needed, since it's = effectively bound to the active key anyway. > EDITORIAL COMMENTS Fixed separately.... Joe --------------enigE118A070FCD485B77E83166F 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 iD8DBQFH1eCQE5f5cImnZrsRAllHAKDo/WvgfbrU52AMgJ5ohFwOINKvYgCg5x0u EHY8Tv0u6qWefoMybdZ95wk= =1QMC -----END PGP SIGNATURE----- --------------enigE118A070FCD485B77E83166F-- --===============1136996603== 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 --===============1136996603==-- From tcpm-bounces@ietf.org Tue Mar 11 04:54:45 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4D728C37C; Tue, 11 Mar 2008 04:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.908 X-Spam-Level: X-Spam-Status: No, score=-99.908 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 oZphyH2UozMQ; Tue, 11 Mar 2008 04:54:43 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA4728C223; Tue, 11 Mar 2008 04:54:43 -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 726C33A6A5B for ; Tue, 11 Mar 2008 04:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 K84Vcd85yi-m for ; Tue, 11 Mar 2008 04:54:38 -0700 (PDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) by core3.amsl.com (Postfix) with ESMTP id 3B8163A6882 for ; Tue, 11 Mar 2008 04:54:38 -0700 (PDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id A85891AB2B9; Tue, 11 Mar 2008 07:52:20 -0400 (EDT) Date: Tue, 11 Mar 2008 07:52:20 -0400 From: Eric Rescorla To: Joe Touch In-Reply-To: <47D5E09A.5000803@isi.edu> References: <47D5E09A.5000803@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080311115220.A85891AB2B9@kilo.rtfm.com> Cc: IETF Security Area WG , tcpm@ietf.org Subject: Re: [tcpm] discussion of draft-rescorla-tcp-auth-arch-00.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-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 At Mon, 10 Mar 2008 18:30:02 -0700, Joe Touch wrote: > > Network Working Group E. Rescorla > > Internet-Draft RTFM, Inc. > > Intended status: Informational March 09, 2008 > > Expires: September 10, 2008 > > > > > > Notes on TCP Authentication Architectures > > draft-rescorla-tcp-auth-arch-00.txt > ... > > 1. Introduction > ... > > Note that there is currently two documents > > [I-D.ietf-tcpm-tcp-auth-opt] [I-D.bellovin-tcpsec] that discuss > > additional requirements, but it's not clear to me that these > > requirements have consensus or in fact are correct. > > The documents were presented at the last IETF, where we solicited > comments on those requirements. The requirements were presented as > having the consensus of the TCP-AO design team only at that time. Sure. I was just trying to say that I wasn't taken them as a given for the purposes of this document. > > 3. Keys and Associations > > > > Probably the most important architectural question is the > > relationship of keys to associations. As indicated above, TCP MD5 > > uses a single static key for all associations. This key is > > configured in a pairwise fashion. By contrast, conventional channel > > security protocols such as TLS [RFC4346] or IPsec [RFC4301] establish > > a fresh set of keying material for each association. The proposed > > TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] also requires > > (though does not arrange for) a fresh key for each association. > > TCP-AO is identical to IPsec [i.e., 4301] in that regard; neither > arranges for keys, and both rely on a separate protocol to do so, in the > sense that IPsec relies on IKE. It's similar to IPsec but not identical, in that IPsec's notion of an association spans multiple TCP connections. > > >> New TSAD entries MUST be checked against a table of previously > > used TSAD entries, and key reuse MUST be prohibited. > > > > There are two good (and one not so good) reasons why it's desirable > > to have mechanisms for changing keys: > > Changing keys is not related to the above key reuse issue AFAICT. Well, part of my point in this section is to distinguish these cases in which one might or might not wish to use different keys at different times. > Key changes are to reduce the amount of material signed under a single > key, to reduce the utility of signed packets to a cryptoanalyst. As I indicate in S 3.3, while this is certainly crypto lore for symmetric ciphers, I am unaware of any evidence that having large (but practical) numbers of plaintext/ciphertext pairs is of any significant value in attacking modern algorithms. > Key reuse is critical to preventing replay attacks within a connection > ID (src IP, dst IP, src port, dst port, aka socket pair). It is useful > to avoid keying different ports or even different hosts with the same > key, but only in a general sense (i.e., to again reduce the amount of > material signed with a single key). I'm not sure which issue you're referring to here by "within a socket pair". - With a single connection. - Between connections which happen to share parameters by coincidence. As I indicate in S 3.1, there's no replay issue in the first case except for TCP sequence number rollover, which can be fixed by using extended sequence numbers. The relevant issue is the second case, again discussed in S 3.1, but it's not clear to me how important this actually is. > > o To arrange for different cryptographic keying material to be used > > for each connection, thus preventing cut-and-paste attacks between > > connections. (Good) > > Those don't seem relevant; the ports change, so the signatures would change. Yes, I'm talking about the second of the two issues above. > > o To limit the amount of plaintext/MAC pairs available to the > > attacker (Not-so-good) > > Is that the 'amount of keyed material' kind of stuff above? That was > given by Bellovin as an issue with TCP-MD5. Yes, presumably. As I say, I'm unaware of any cryptographic issue here. > > In TCP, cut-and-paste attacks are also possible within a connection > > due to sequence number rollover. This can be fixed, however, by > > extending the sequence numbers virtually, as done with ESP/AH. > > We definitely do not want to tie the keying directly to the sequence > space for a variety of reasons (we listed some, I believe); this is done > indirectly by bytecounts or packet counts to trigger key changes. The only mention of sequence number in your draft is in S 9: Value (ICV). In TCP-AO, the socket pair performs most of the function of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay attacks, isn't needed due to TCP's Sequence Number, which is used to reorder received segments. Unfortunately, it is not useful to validate TCP's Sequence Number before performing a TCP-AO authentication calculation, because many out-of-window segments still cause TCP protocol actions (e.g., ACK retransmission) [RFC793]. It is similarly not useful to add a separate Sequence Number field to the TCP-AO option, because doing so could cause a change in TCP's behavior even when segments are valid. But this is not what I'm talking about. I'm merely talking about using the ISNs as a diversifier for the per-connection key. Could you elaborate more on issues with this. > > 6.2.1. Internal Key Management Protocol > > > > The traditional approach to this problem would be to build a KMP into > > TCP. This would presumably entail designing a new crypto protocol > > (no small job) which is then carried in a TCP option. > > TCP option space is already consumed by a number of commonly used > options, and we want to retain space for additional options where > possible. Space is most limited in the SYN packet, which is where the > initial key exchange would occur. > > Because there isn't enough TCP option space for this sort of solution, > we excluded it as a possibility. I tend to agree that this is not that attractive an alternative. > > 6.2.3. Layered KMP > > > > Another way to provide a separate KMP is to bind it more tightly to > > the transport protocol by running it over (or next to, as in DTLS- > > SRTP [I-D.ietf-avt-dtls-srtp]) the transport protocol. At the time > > that the association is created, the application initiating the > > association also initiates a KMP exchange over (next to) the > > transport protocol. When the KMP terminates, it outputs keying and > > parameter information and imposes them on the association. In the > > case of TLS over TCP, this would look something like: > > > > TCP Client TCP Server > > ---------- ---------- > > TCP SYN -------------------------------------> > > <---------------------------------- TCP SYN/ACK > > TCP ACK -------------------------------------> > > <--------- TLS Handshake (over TCP) ------> > > Keys to TCP Keys to TCP > > App data (protected with TCP integrity) -----> > > <----- App data (protected with TCP integrity) > > This fails to protect the SYN exchange, which we consider a requirement. I certainly agree that it does not protect the SYN. I noted it as the second major disadvantage. As for whether this is a requirement, I think that's deserving of some discussion. > It also changes state from non-keyed to keyed; it would be very > difficult to introduce that sort of stateful change inside the TCP > protocol in ways that affect the data stream, since no other options > have that kind of effect (i.e., of affecting all data after some point). I'm no expert on TCP options and I'm certainly prepared to believe that no other options have this effect, but I'm not sure I see the issue here as to why this is a problem. The sides can simply place the option in the segment keyed with some null key and algorithm (e.g., all zero MAC) and then start processing when the key is set. As I recall, a similar algorithm is used in SCTP-AUTH. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 11 04:56:20 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A3D28C276; Tue, 11 Mar 2008 04:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.086 X-Spam-Level: X-Spam-Status: No, score=-100.086 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 IF9F2C1p4E18; Tue, 11 Mar 2008 04:56:16 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB6028C255; Tue, 11 Mar 2008 04:56:16 -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 6C4E628C255 for ; Tue, 11 Mar 2008 04:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 c-FLuIIalD40 for ; Tue, 11 Mar 2008 04:56:14 -0700 (PDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) by core3.amsl.com (Postfix) with ESMTP id 4255C28C19F for ; Tue, 11 Mar 2008 04:56:14 -0700 (PDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 17B5F1AB2D2; Tue, 11 Mar 2008 07:53:57 -0400 (EDT) Date: Tue, 11 Mar 2008 07:53:57 -0400 From: Eric Rescorla To: Joe Touch In-Reply-To: <47D5E090.9010608@isi.edu> References: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> <47D5E090.9010608@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080311115357.17B5F1AB2D2@kilo.rtfm.com> Cc: saag@mit.edu, tcpm@ietf.org Subject: Re: [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00 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-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 At Mon, 10 Mar 2008 18:29:52 -0700, Joe Touch wrote: > Also, I would expect that most of these issues would be useful to > discuss further in TCPM if you're available. Otherwise, we could meet > separately... I do plan to try to attend TCPM. > > GENERAL COMMENTS > > I'm not convinced it's necessary to have a new key for each > > connection. This is primarily useful to prevent inter-connection > > cut-and-paste attacks, and it's not clear how serious those > > are. > > It's there primarily to prevent packets from an old version of a > connection from being used on a new connection, i.e., replay attacks > between a connection and its successor using the same port pair. Right, that's what I mean by "inter-connection cut and paste attacks". I'd like to see some analysis of how serious they are. > > I think it's particularly problematic to levy this > > requirement without providing some mechanism for arranging > > that, since that basically implies having some automatic > > mechanism for establishing fresh per-connection keys, which > > doesn't currently exist. That makes this mechanism distinctly > > less useful than RFC 2385. > > It does imply that for systems that re-establish connections frequently > either a a fresh key generation system is available, or a fairly long > list is preloaded. Right, so absent the definition of such a mechanism, this is less useful than 2385. > > I don't think this API, specification of the TSAD, etc., is > > particularly helpful. IPsec needed the concept of an association > > database because packets corresponding to multiple associations > > got similar treatment. However, TCP has an explicit notion > > of connection so it would be far more convenient to simply > > refer to keys as tied to connections, and then have a set > > of rules for mapping which connections get which keys. > > That's exactly what the TSAD is (or at least is supposed to be). It > might be useful to discuss this offline to figure out what the > disconnect is... Perhaps. I think expressing it as a database isn't particularly helpful. There are structures associated with the connection and it's most useful (IMO) to think of this data as attached to them, just as (for instance) the current window or sequence number is. > > Even if some TSAD-type abstraction is useful, I don't think > > it's appropriate to define things like the size of each > > parameter in the TSAD as opposed to on the wire, > > The TSAD API needs to be specified in detail because the key management > solution needs to rely on that information. > > > or to > > describe the default values of various parameters as in > > S 3. For instance: > > > > iii. Key length. A byte indicating the length of the > > connection key in bytes. > > > > Those are internal implementation issues. Certainly, I might > > want to use a native int in my implementation. Why should > > this document tell me otherwise? > > Again, it's to allow another party - the key management solution - to > load the TSAD. I really don't see this. The other party presumably has some set of API calls/IPC/whatever, that it talks to. It's not our job to specify the interface between those to, other than the contents of the elements. > > S 3. > > >> At least one direction (inbound/outbound) SHOULD have > > a non-NONE MAC in practice, but this MUST NOT be strictly > > required by an implementation. > > > > 1. This seems like a bad idea. It's very hard to analyze the security > > properties of a connection when only one side is protected. To take > > one case that is obviously bad, if you're worried about DoS attacks > > and you use TCP-AO, then forging packets in either direction can > > bring it down. I would reverse this and require MACs in both directions. > > For BGP, this is important. For servers, it's not necessarily feasible - > clients may authenticate the server, but the converse may not > necessarily be true. I don't see why it's not feasible. They share a key, so there's no reason not to have mutual auth. > Yes, this allows attacks in one direction to > succeed, but it also isn't clear that both directions are equally > vulnerable, is it? I don't see this. The relevant attack here is to bring down the connection. An RST in either direction will accomplish that. Thus, ISTM that packets need to be authenticated in both directions. > > 2. Even if we stipulate that this might be an OK idea, it's not > > appropriate to require implementations to support it. > > I'm not sure I understand this; if we say that connections MAY have > unidirectional auth, then it seems like the implementation MUST support > that capability. I don't see that that's true. For instance, TLS stacks MAY support RC4, but we don't require them to support RC4. > > S 4.1. > > >> New TSAD entries MUST be checked against a table of previously > > used TSAD entries, and key reuse MUST be prohibited. > > > > Huh? So, I have to keep a list of every TSAD entry ever and check > > against the table. Seems better to just to do this by construction. > > I'm not sure what "by construction" means, but that's certainly better > if possible. Can you suggest text or explain this off-line? I mean that if you randomly generate keys for the TSAD with an appropriate algorithm then there is no reasonable chance that there will be a collision. > > S 5.1. > > o Number of bytes to be sent/received (two bytes); this is used on > > the send side to trigger bytecount-based KeyID changes, and on the > > receive side only for statistics or length-sensitive KeyID > > selection. > > > > Please explain the cryptographic rationale for why you would want to > > do bytecount based key changes. > > That part of the API is strawman; we expect to need to count either > messages or bytes or both. If message counts are more useful, then we > can change to that. I don't see that you need to count either. > > S 9. > > TCP-AO does not expose the MAC algorithm used to authenticate a > > particular connection; that information is kept in the TSAD at the > > endpoints, and is not indicated in the header. > > > > This seems to be of extremely marginal security benefit. There > > are likely to be <5 algorithms in use. So, searching all of them > > increases the effective key size by <3 bits. > > The other reason to not include it is space; it's not needed, since it's > effectively bound to the active key anyway. That's totally reasonable. I'm not saying it has to be included, just that I don't see not including it as a significant security benefit. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 11 05:25:13 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9329F28C3D1; Tue, 11 Mar 2008 05:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.985 X-Spam-Level: X-Spam-Status: No, score=-99.985 tagged_above=-999 required=5 tests=[AWL=-0.788, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] 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 XyjlVg6T6jji; Tue, 11 Mar 2008 05:25:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509CA3A6D3A; Tue, 11 Mar 2008 05:25:12 -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 B7F613A6D3A for ; Tue, 11 Mar 2008 05:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 2RUKavIGHXP1 for ; Tue, 11 Mar 2008 05:25:09 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 921FA28C379 for ; Tue, 11 Mar 2008 05:25:09 -0700 (PDT) Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2BCISgC014611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Mar 2008 05:18:29 -0700 (PDT) Message-ID: <47D6784B.3030107@isi.edu> Date: Tue, 11 Mar 2008 05:17:15 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <47D5E09A.5000803@isi.edu> <20080311115220.A85891AB2B9@kilo.rtfm.com> In-Reply-To: <20080311115220.A85891AB2B9@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF Security Area WG , tcpm@ietf.org Subject: Re: [tcpm] discussion of draft-rescorla-tcp-auth-arch-00.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-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1795952969==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1795952969== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEB93B1C241DC34622A0B2F1D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB93B1C241DC34622A0B2F1D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: =2E.. >>> 3. Keys and Associations >>> >>> Probably the most important architectural question is the >>> relationship of keys to associations. As indicated above, TCP MD5= >>> uses a single static key for all associations. This key is >>> configured in a pairwise fashion. By contrast, conventional chann= el >>> security protocols such as TLS [RFC4346] or IPsec [RFC4301] establ= ish >>> a fresh set of keying material for each association. The proposed= >>> TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] also requir= es >>> (though does not arrange for) a fresh key for each association. >> >> TCP-AO is identical to IPsec [i.e., 4301] in that regard; neither=20 >> arranges for keys, and both rely on a separate protocol to do so, in t= he=20 >> sense that IPsec relies on IKE. >=20 > It's similar to IPsec but not identical, in that IPsec's notion of an > association spans multiple TCP connections. There are numerous differences, however, regarding the statement "does=20 not arrange for) a fresh key for each association", they are identical IM= O. >>> >> New TSAD entries MUST be checked against a table of previous= ly >>> used TSAD entries, and key reuse MUST be prohibited. >>> >>> There are two good (and one not so good) reasons why it's desirabl= e >>> to have mechanisms for changing keys: >> >> Changing keys is not related to the above key reuse issue AFAICT. >=20 > Well, part of my point in this section is to distinguish these > cases in which one might or might not wish to use different > keys at different times. Agreed. Unless your doc is intended to be longer term, it's not an issue.= >> Key changes are to reduce the amount of material signed under a single= =20 >> key, to reduce the utility of signed packets to a cryptoanalyst. >=20 > As I indicate in S 3.3, while this is certainly crypto lore for > symmetric ciphers, I am unaware of any evidence that having > large (but practical) numbers of plaintext/ciphertext pairs=20 > is of any significant value in attacking modern algorithms. That lore is expressed in RFC3562,and implied in RFC4107 in the phrase=20 "short term" key. We'd be glad to be advised otherwise; if so, then: - we could note that the key-ID would be used only for deliberate key changes, e.g., due to compromise, or to avoid a key rollover replay attack note: this is also why we need a byte/segment counter; when it hits 2^32, we MUST change keys or there is a clear replay attack - we could ignore the reuse of keys across different connections within the same machine, though we'd still want to avoid reuse within a connection ID due to replay attacks >> Key reuse is critical to preventing replay attacks within a connection= =20 >> ID (src IP, dst IP, src port, dst port, aka socket pair). It is useful= =20 >> to avoid keying different ports or even different hosts with the same = >> key, but only in a general sense (i.e., to again reduce the amount of = >> material signed with a single key). >=20 > I'm not sure which issue you're referring to here by "within a socket > pair". It's defined in RFC793 as [srcIP, dstIP, srcport, dstport]; it defines a = TCP connection, and noted as such in sec 3 of the tcp-auth I-D. > - With a single connection. > - Between connections which happen to share parameters by coincidence. >=20 > As I indicate in S 3.1, there's no replay issue in the first case > except for TCP sequence number rollover, which can be fixed by > using extended sequence numbers.=20 TCP does not have extended sequence numbers. Adding that=20 cross-connection information, and including it in every tcp-opt header,=20 was explored but is decided against for numerous reasons. > The relevant issue is the > second case, again discussed in S 3.1, but it's not clear to > me how important this actually is. That's why we believe it's sufficient to address this at the TSAD,=20 requiring keys to change when connections end and new ones start with=20 the same port numbers. That can be accomplished in various ways, e.g., by= : - forcing a TSAD key change - keeping a cache of previous TSAD keys for that connection etc. The first one above might be sufficient - and simple to implement - if=20 this is not a severe concern. =2E.. >>> In TCP, cut-and-paste attacks are also possible within a connectio= n >>> due to sequence number rollover. This can be fixed, however, by >>> extending the sequence numbers virtually, as done with ESP/AH. >> >> We definitely do not want to tie the keying directly to the sequence=20 >> space for a variety of reasons (we listed some, I believe); this is do= ne=20 >> indirectly by bytecounts or packet counts to trigger key changes. >=20 > The only mention of sequence number in your draft is in S 9: >=20 > Value (ICV). In TCP-AO, the socket pair performs most of the functio= n=20 > of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay=20 > attacks, isn't needed due to TCP's Sequence Number, which is used to= =20 > reorder received segments. Unfortunately, it is not useful to=20 > validate TCP's Sequence Number before performing a TCP-AO=20 > authentication calculation, because many out-of-window segments stil= l=20 > cause TCP protocol actions (e.g., ACK retransmission) [RFC793]. It i= s=20 > similarly not useful to add a separate Sequence Number field to the = > TCP-AO option, because doing so could cause a change in TCP's=20 > behavior even when segments are valid.=20 Thanks for rechecking; we can add text to capture our previous thoughts=20 on this, though, as you note below, that's not important here. > But this is not what I'm talking about. I'm merely talking about > using the ISNs as a diversifier for the per-connection key. > Could you elaborate more on issues with this. Are you suggesting instead to retain the ISN for a connection and use it = in the crypto alg? TCP doesn't currently require any specific entropy in = the ISN change; if it's sufficient that it change, this might be a way=20 to achieve the lack of key reuse. >>> 6.2.3. Layered KMP >>> >>> Another way to provide a separate KMP is to bind it more tightly t= o >>> the transport protocol by running it over (or next to, as in DTLS-= >>> SRTP [I-D.ietf-avt-dtls-srtp]) the transport protocol. At the tim= e >>> that the association is created, the application initiating the >>> association also initiates a KMP exchange over (next to) the >>> transport protocol. When the KMP terminates, it outputs keying an= d >>> parameter information and imposes them on the association. In the= >>> case of TLS over TCP, this would look something like: >>> >>> TCP Client TCP Server >>> ---------- ---------- >>> TCP SYN -------------------------------------> >>> <---------------------------------- TCP SYN/ACK >>> TCP ACK -------------------------------------> >>> <--------- TLS Handshake (over TCP) ------> >>> Keys to TCP Keys to T= CP >>> App data (protected with TCP integrity) -----> >>> <----- App data (protected with TCP integrity) >> This fails to protect the SYN exchange, which we consider a requiremen= t.=20 >=20 > I certainly agree that it does not protect the SYN. I noted it as > the second major disadvantage. As for whether this is a requirement, > I think that's deserving of some discussion. >=20 >=20 >> It also changes state from non-keyed to keyed; it would be very=20 >> difficult to introduce that sort of stateful change inside the TCP=20 >> protocol in ways that affect the data stream, since no other options=20 >> have that kind of effect (i.e., of affecting all data after some point= ). >=20 > I'm no expert on TCP options and I'm certainly prepared to believe > that no other options have this effect, but I'm not sure I see > the issue here as to why this is a problem. The sides can simply > place the option in the segment keyed with some null key and > algorithm (e.g., all zero MAC) and then start processing when > the key is set. As I recall, a similar algorithm is used in > SCTP-AUTH. We'll raise that today at TCPM, but I expect that all state associated=20 with a TCP connection will continue to be negotiated solely at SYN time. = Agreed that this is not the case for other stateful protocols. Joe --------------enigEB93B1C241DC34622A0B2F1D 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 iD8DBQFH1nhLE5f5cImnZrsRAkkXAJ98fO1wHOTR360hYZnpo/jPRBK2hACdG6Zu 2zkgm++bPMHUvTpFcYKJFC8= =l86h -----END PGP SIGNATURE----- --------------enigEB93B1C241DC34622A0B2F1D-- --===============1795952969== 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 --===============1795952969==-- From tcpm-bounces@ietf.org Tue Mar 11 05:36:42 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A20128C3C7; Tue, 11 Mar 2008 05:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.431 X-Spam-Level: X-Spam-Status: No, score=-100.431 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 gkI0IwLRwkGM; Tue, 11 Mar 2008 05:36:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF1A3A6A81; Tue, 11 Mar 2008 05:36:40 -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 72EC628C3B7 for ; Tue, 11 Mar 2008 05:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 disOyR+ZWT+h for ; Tue, 11 Mar 2008 05:36:38 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2C72D28C381 for ; Tue, 11 Mar 2008 05:36:38 -0700 (PDT) Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2BCX2xm019868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Mar 2008 05:33:04 -0700 (PDT) Message-ID: <47D67BCD.7030508@isi.edu> Date: Tue, 11 Mar 2008 05:32:13 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> <47D5E090.9010608@isi.edu> <20080311115357.17B5F1AB2D2@kilo.rtfm.com> In-Reply-To: <20080311115357.17B5F1AB2D2@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: saag@mit.edu, tcpm@ietf.org Subject: Re: [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00 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-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0733470578==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0733470578== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE5DDAAD1A38E1B3593A26CDE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE5DDAAD1A38E1B3593A26CDE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Eric, Eric Rescorla wrote: =2E.. >>> GENERAL COMMENTS >>> I'm not convinced it's necessary to have a new key for each >>> connection. This is primarily useful to prevent inter-connection >>> cut-and-paste attacks, and it's not clear how serious those >>> are.=20 >> It's there primarily to prevent packets from an old version of a=20 >> connection from being used on a new connection, i.e., replay attacks=20 >> between a connection and its successor using the same port pair. >=20 > Right, that's what I mean by "inter-connection cut and paste attacks". > I'd like to see some analysis of how serious they are.=20 They would be obvious opportunities for on-path attackers. As per my=20 other reply this AM, using the ISN in the hash might avoid this issue=20 entirely. >>> I think it's particularly problematic to levy this >>> requirement without providing some mechanism for arranging >>> that, since that basically implies having some automatic >>> mechanism for establishing fresh per-connection keys, which >>> doesn't currently exist. That makes this mechanism distinctly >>> less useful than RFC 2385. >> >> It does imply that for systems that re-establish connections frequentl= y=20 >> either a a fresh key generation system is available, or a fairly long = >> list is preloaded. >=20 > Right, so absent the definition of such a mechanism, this is less > useful than 2385. Absolutely. We agree that an auto key mechanism is critical; we feel=20 that, like IPsec, it's not integral. >>> I don't think this API, specification of the TSAD, etc., is >>> particularly helpful. IPsec needed the concept of an association >>> database because packets corresponding to multiple associations >>> got similar treatment. However, TCP has an explicit notion >>> of connection so it would be far more convenient to simply >>> refer to keys as tied to connections, and then have a set >>> of rules for mapping which connections get which keys. >> That's exactly what the TSAD is (or at least is supposed to be). It=20 >> might be useful to discuss this offline to figure out what the=20 >> disconnect is... >=20 > Perhaps. I think expressing it as a database isn't particularly > helpful. There are structures associated with the connection > and it's most useful (IMO) to think of this data as attached > to them, just as (for instance) the current window or sequence > number is. Agreed, and that information is deliberately not accessible. Expression=20 of the info as a dbase is equivalent to how TCP describes a "control=20 block". The important issue is the info in each entry, and the index by=20 which they're differentiated. >>> Even if some TSAD-type abstraction is useful, I don't think >>> it's appropriate to define things like the size of each >>> parameter in the TSAD as opposed to on the wire,=20 >> >> The TSAD API needs to be specified in detail because the key managemen= t=20 >> solution needs to rely on that information. >> >>> or to >>> describe the default values of various parameters as in >>> S 3. For instance: >>> >>> iii. Key length. A byte indicating the length of the=20 >>> connection key in bytes. =20 >>> >>> Those are internal implementation issues. Certainly, I might >>> want to use a native int in my implementation. Why should >>> this document tell me otherwise? >> >> Again, it's to allow another party - the key management solution - to = >> load the TSAD. >=20 > I really don't see this. The other party presumably has some set of > API calls/IPC/whatever, that it talks to. It's not our job to > specify the interface between those to, other than the contents > of the elements.=20 That's basically all we do - contents, order, and size of each element=20 in each direction. >>> S 3. >>> >> At least one direction (inbound/outbound) SHOULD ha= ve=20 >>> a non-NONE MAC in practice, but this MUST NOT be stric= tly=20 >>> required by an implementation. =20 >>> >>> 1. This seems like a bad idea. It's very hard to analyze the security= >>> properties of a connection when only one side is protected. To take >>> one case that is obviously bad, if you're worried about DoS attacks >>> and you use TCP-AO, then forging packets in either direction can >>> bring it down. I would reverse this and require MACs in both directio= ns. >> >> For BGP, this is important. For servers, it's not necessarily feasible= -=20 >> clients may authenticate the server, but the converse may not=20 >> necessarily be true. >=20 > I don't see why it's not feasible. They share a key, so there's > no reason not to have mutual auth. There are cases I can think of - akin to well-known CAs used by web=20 browsers used over wireless channels (see below). >> Yes, this allows attacks in one direction to=20 >> succeed, but it also isn't clear that both directions are equally=20 >> vulnerable, is it? >=20 > I don't see this. The relevant attack here is to bring down the > connection. An RST in either direction will accomplish that. The question is whether a RST in either direction is as easy to inject.=20 There are media with dedicated uplinks and shared downlinks for which=20 this is the case, e.g., some wireless nets. Note that this is all just my playing devils' advocate about whether=20 this is needed; if we agree that we should always require bidirectional=20 auth, then it's a trivial patch to the doc to do so. >>> 2. Even if we stipulate that this might be an OK idea, it's not >>> appropriate to require implementations to support it. >> >> I'm not sure I understand this; if we say that connections MAY have=20 >> unidirectional auth, then it seems like the implementation MUST suppor= t=20 >> that capability. >=20 > I don't see that that's true. For instance, TLS stacks MAY support > RC4, but we don't require them to support RC4. I understand now. I am thinking of this as a required feature; again, if = the TCPM WG and/or SAAG thinks this is either MUST NOT or MAY, then it's = an easy change. >>> S 4.1. >>> >> New TSAD entries MUST be checked against a table of previously = >>> used TSAD entries, and key reuse MUST be prohibited.=20 >>> >>> Huh? So, I have to keep a list of every TSAD entry ever and check >>> against the table. Seems better to just to do this by construction. >> >> I'm not sure what "by construction" means, but that's certainly better= =20 >> if possible. Can you suggest text or explain this off-line? >=20 > I mean that if you randomly generate keys for the TSAD with an > appropriate algorithm then there is no reasonable chance that there > will be a collision. That requires the TSAD only ever be loaded by an automatic key manager,=20 AND that only one such manager ever exist. We don't want to require=20 either for all implementations, thus the TSAD must enforce whatever is=20 needed in this regard. Again, the other email of this AM might suggest a simpler way out using=20 ISNs in the hash. >>> S 5.1. >>> o Number of bytes to be sent/received (two bytes); this is used o= n=20 >>> the send side to trigger bytecount-based KeyID changes, and on = the=20 >>> receive side only for statistics or length-sensitive KeyID=20 >>> selection.=20 >>> >>> Please explain the cryptographic rationale for why you would want to >>> do bytecount based key changes. >> >> That part of the API is strawman; we expect to need to count either=20 >> messages or bytes or both. If message counts are more useful, then we = >> can change to that. >=20 > I don't see that you need to count either.=20 I recalled this; it's for sequence number rollover. There are TCP=20 connections that send more than 2^32 bytes. We MUST rollover keys when=20 that happens, and we do not want to tie the key system to internal TCP=20 state. >>> S 9. >>> TCP-AO does not expose the MAC algorithm used to authenticate a=20 >>> particular connection; that information is kept in the TSAD at the= =20 >>> endpoints, and is not indicated in the header.=20 >>> >>> This seems to be of extremely marginal security benefit. There >>> are likely to be <5 algorithms in use. So, searching all of them >>> increases the effective key size by <3 bits.=20 >> >> The other reason to not include it is space; it's not needed, since it= 's=20 >> effectively bound to the active key anyway. >=20 > That's totally reasonable. I'm not saying it has to be included, just t= hat > I don't see not including it as a significant security benefit. It's not significant, agreed. We might omit that from the doc as a=20 result if others agree. Joe --------------enigE5DDAAD1A38E1B3593A26CDE 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 iD8DBQFH1nvNE5f5cImnZrsRAk5+AKC4hRqj2XfVL3fyN31jfyXQjVHClACfe1Rz uYoJ/WXm39+osLvdfq4fozA= =FjWK -----END PGP SIGNATURE----- --------------enigE5DDAAD1A38E1B3593A26CDE-- --===============0733470578== 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 --===============0733470578==-- From tcpm-bounces@ietf.org Tue Mar 11 05:41:18 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9566F28C3A3; Tue, 11 Mar 2008 05:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.484 X-Spam-Level: X-Spam-Status: No, score=-99.484 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] 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 ZBPe4VJUQJjI; Tue, 11 Mar 2008 05:41:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A76828C379; Tue, 11 Mar 2008 05:41:17 -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 4DF4B28C384 for ; Tue, 11 Mar 2008 05:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 o4wI+UPiv2m4 for ; Tue, 11 Mar 2008 05:41:11 -0700 (PDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) by core3.amsl.com (Postfix) with ESMTP id AF8A128C334 for ; Tue, 11 Mar 2008 05:41:11 -0700 (PDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 9CF841AB60F; Tue, 11 Mar 2008 08:38:51 -0400 (EDT) Date: Tue, 11 Mar 2008 08:38:51 -0400 From: Eric Rescorla To: Joe Touch In-Reply-To: <47D6784B.3030107@isi.edu> References: <47D5E09A.5000803@isi.edu> <20080311115220.A85891AB2B9@kilo.rtfm.com> <47D6784B.3030107@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080311123851.9CF841AB60F@kilo.rtfm.com> Cc: IETF Security Area WG , tcpm@ietf.org Subject: Re: [tcpm] discussion of draft-rescorla-tcp-auth-arch-00.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-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 At Tue, 11 Mar 2008 05:17:15 -0700, Joe Touch wrote: > Eric Rescorla wrote: > >> Key changes are to reduce the amount of material signed under a single > >> key, to reduce the utility of signed packets to a cryptoanalyst. > > > > As I indicate in S 3.3, while this is certainly crypto lore for > > symmetric ciphers, I am unaware of any evidence that having > > large (but practical) numbers of plaintext/ciphertext pairs > > is of any significant value in attacking modern algorithms. > > That lore is expressed in RFC3562,and implied in RFC4107 in the phrase > "short term" key. We'd be glad to be advised otherwise; if so, then: > > - we could note that the key-ID would be used only for > deliberate key changes, e.g., due to compromise, or to > avoid a key rollover replay attack > > note: this is also why we need a byte/segment > counter; when it hits 2^32, we MUST change > keys or there is a clear replay attack As I stated in my original document, this is not correct. You simply treat the sequence number as 64 bits long with only the low order 32-bits represented on the wire, but include the entire sequence number in the MAC. The relevant technique is described in RFC 4304. > > - With a single connection. > > - Between connections which happen to share parameters by coincidence. > > > > As I indicate in S 3.1, there's no replay issue in the first case > > except for TCP sequence number rollover, which can be fixed by > > using extended sequence numbers. > > TCP does not have extended sequence numbers. Adding that > cross-connection information, and including it in every tcp-opt header, > was explored but is decided against for numerous reasons. As noted above, this is not included on the wire. > > The relevant issue is the > > second case, again discussed in S 3.1, but it's not clear to > > me how important this actually is. > > That's why we believe it's sufficient to address this at the TSAD, > requiring keys to change when connections end and new ones start with > the same port numbers. That can be accomplished in various ways, e.g., by: > - forcing a TSAD key change > - keeping a cache of previous TSAD keys for that connection > etc. > > The first one above might be sufficient - and simple to implement - if > this is not a severe concern. Well, you're assuming that it's something we need to do at all. Given that it comes at some cost, I think it should be discussed first. > > But this is not what I'm talking about. I'm merely talking about > > using the ISNs as a diversifier for the per-connection key. > > Could you elaborate more on issues with this. > > Are you suggesting instead to retain the ISN for a connection and use it > in the crypto alg? See S 6.1.2. K_connection = HMAC(K_static, ISN_client || ISN_server) -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 11 05:49:01 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3A028C1D4; Tue, 11 Mar 2008 05:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.149 X-Spam-Level: X-Spam-Status: No, score=-100.149 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 n+qF-vowyqbK; Tue, 11 Mar 2008 05:48:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203713A6DB7; Tue, 11 Mar 2008 05:48: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 A0E8B3A6AFF for ; Tue, 11 Mar 2008 05:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 d30WVbrEG8SD for ; Tue, 11 Mar 2008 05:48:51 -0700 (PDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) by core3.amsl.com (Postfix) with ESMTP id 9B6E33A6D91 for ; Tue, 11 Mar 2008 05:48:51 -0700 (PDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id AFB0C1AB68D; Tue, 11 Mar 2008 08:46:31 -0400 (EDT) Date: Tue, 11 Mar 2008 08:46:31 -0400 From: Eric Rescorla To: Joe Touch In-Reply-To: <47D67BCD.7030508@isi.edu> References: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> <47D5E090.9010608@isi.edu> <20080311115357.17B5F1AB2D2@kilo.rtfm.com> <47D67BCD.7030508@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080311124631.AFB0C1AB68D@kilo.rtfm.com> Cc: saag@mit.edu, tcpm@ietf.org Subject: Re: [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00 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-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 Information is getting spread over two threads here, so I will be repeating myself a bit. At Tue, 11 Mar 2008 05:32:13 -0700, Joe Touch wrote: > >>> I don't think this API, specification of the TSAD, etc., is > >>> particularly helpful. IPsec needed the concept of an association > >>> database because packets corresponding to multiple associations > >>> got similar treatment. However, TCP has an explicit notion > >>> of connection so it would be far more convenient to simply > >>> refer to keys as tied to connections, and then have a set > >>> of rules for mapping which connections get which keys. > >> That's exactly what the TSAD is (or at least is supposed to be). It > >> might be useful to discuss this offline to figure out what the > >> disconnect is... > > > > Perhaps. I think expressing it as a database isn't particularly > > helpful. There are structures associated with the connection > > and it's most useful (IMO) to think of this data as attached > > to them, just as (for instance) the current window or sequence > > number is. > > Agreed, and that information is deliberately not accessible. Expression > of the info as a dbase is equivalent to how TCP describes a "control > block". The important issue is the info in each entry, and the index by > which they're differentiated. I think we're going to have to disagree on this one. > > I really don't see this. The other party presumably has some set of > > API calls/IPC/whatever, that it talks to. It's not our job to > > specify the interface between those to, other than the contents > > of the elements. > > That's basically all we do - contents, order, and size of each element > in each direction. Well "contents" != "contents, order, and size" and I haven't heard a clear demonstration that "order and size" are required". > > I don't see why it's not feasible. They share a key, so there's > > no reason not to have mutual auth. > > There are cases I can think of - akin to well-known CAs used by web > browsers used over wireless channels (see below). Well, I think any case in which you have public key is fundamentally different: shared keys imply an opportunity for utual authentication. > >>> >> New TSAD entries MUST be checked against a table of previously > >>> used TSAD entries, and key reuse MUST be prohibited. > >>> > >>> Huh? So, I have to keep a list of every TSAD entry ever and check > >>> against the table. Seems better to just to do this by construction. > >> > >> I'm not sure what "by construction" means, but that's certainly better > >> if possible. Can you suggest text or explain this off-line? > > > > I mean that if you randomly generate keys for the TSAD with an > > appropriate algorithm then there is no reasonable chance that there > > will be a collision. > > That requires the TSAD only ever be loaded by an automatic key manager, > AND that only one such manager ever exist. We don't want to require > either for all implementations, thus the TSAD must enforce whatever is > needed in this regard. No, I don't agree with this. Rather, implementors must ensure that they don't duplicate entry. If they have two management processes, they need to somehow coordinate (or use independent algorithms). That does not mean that the TSAD needs to verify that. Note that verifying it means retaining records of every key. That seems impractical. > >>> S 5.1. > >>> o Number of bytes to be sent/received (two bytes); this is used on > >>> the send side to trigger bytecount-based KeyID changes, and on the > >>> receive side only for statistics or length-sensitive KeyID > >>> selection. > >>> > >>> Please explain the cryptographic rationale for why you would want to > >>> do bytecount based key changes. > >> > >> That part of the API is strawman; we expect to need to count either > >> messages or bytes or both. If message counts are more useful, then we > >> can change to that. > > > > I don't see that you need to count either. > > I recalled this; it's for sequence number rollover. There are TCP > connections that send more than 2^32 bytes. We MUST rollover keys when > that happens, and we do not want to tie the key system to internal TCP > state. See my previous note for how to do this without rollover using ESNs. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 11 06:11:22 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5813A6B3C; Tue, 11 Mar 2008 06:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 7LBkuM8i23e9; Tue, 11 Mar 2008 06:11:21 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801673A6DD5; Tue, 11 Mar 2008 06:11:21 -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 D48553A6915 for ; Tue, 11 Mar 2008 06:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 0fQv-f50cMYN for ; Tue, 11 Mar 2008 06:11:18 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 0A9713A6D9E for ; Tue, 11 Mar 2008 06:11:18 -0700 (PDT) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m2BD8w4T003877 for ; Tue, 11 Mar 2008 06:08:58 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id A6ADE19DD608 for ; Tue, 11 Mar 2008 09:08:18 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 60D3542356D for ; Tue, 11 Mar 2008 09:08:19 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Blue on Black MIME-Version: 1.0 Date: Tue, 11 Mar 2008 09:08:19 -0400 Message-Id: <20080311130819.60D3542356D@lawyers.icir.org> Subject: [tcpm] meeting details X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0200400911==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0200400911== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The following are some bits and pieces that local and remote participants for today's meeting might find handy. Audio stream: http://videolab.uoregon.edu/events/ietf/ Jabber room: tcpm@jabber.ietf.org Slides: https://datatracker.ietf.org/meeting/71/materials.html allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFH1oRDWyrrWs4yIs4RAtDhAJ9xzpK/Gu3KuiiVxfI6G9owAuOhsACghDhy zUinoqxVCH16q8R0HJY91II= =Ki2v -----END PGP SIGNATURE----- --=_bOundary-- --===============0200400911== 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 --===============0200400911==-- From tcpm-bounces@ietf.org Tue Mar 11 09:50:41 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B734928C41E; Tue, 11 Mar 2008 09:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.76 X-Spam-Level: X-Spam-Status: No, score=-100.76 tagged_above=-999 required=5 tests=[AWL=-0.923, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 aRVqQFNJLbQa; Tue, 11 Mar 2008 09:50:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8693A6985; Tue, 11 Mar 2008 09:50:40 -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 2BA4A3A6985 for ; Tue, 11 Mar 2008 09:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 4xtzKQ8QtkbA for ; Tue, 11 Mar 2008 09:50:33 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A15DB3A6C86 for ; Tue, 11 Mar 2008 09:50:33 -0700 (PDT) Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.54.46.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 11 Mar 2008 09:48:21 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.54.46.186]) with mapi; Tue, 11 Mar 2008 09:48:13 -0700 From: Murari Sridharan To: Pasi Sarolahti Date: Tue, 11 Mar 2008 09:47:34 -0700 Thread-Topic: F-RTO and RFC 3517 interaction issues Thread-Index: AciDDBZURGBdrNFmSbaMa3csR5zchgAf/jgwAAJPPHA= Message-ID: References: <7D419A49-15F9-450F-B51B-C217123475F7@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] F-RTO and RFC 3517 interaction issues 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-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 The main issue I see is that without maintaining extra state how do you know which situation you are in? I think the draft should clarify how exactly this should be done to avoid incorrect implementations. Here are the cases as I see it broadly there are two cases but its really 3 sub-cases. The cases are as FRTO sees the TCP state when it is about to classify a timeout. a) This is the simplest case when timeout has happened without any prior recovery attempt. Setting Recover = SndUna works fine here. b) Recovery in progress. Fast retransmit is triggered, 3517 may be active, now the timeout happens. If SPUR_TO, Recover = SndUna is ok for the reasons you outline below. c) Recovery in progress like (b), timeout happens but this is a real timeout. Now next phase starts with valid Recover value based on 3517. Another timeout happens before Recover is crossed, now *without any additional state* there is no way to differentiate this from case (b). There should be some additional state associated with the value stored in Recover which is if FRTO declared a real timeout. Now you can say only reset Recover = SndUna only if Recover is not associated with a real timeout. If we want to avoid implementation bugs we need to be prescriptive here so it may not be enough to say " On the other hand, the draft says that F-RTO SHOULD NOT be applied when an earlier SACK recovery is in progress" Because it doesn't clarify how case (b) is different from (c). In both cases an earlier SACK recovery is in progress. Hope this helps. Murari -----Original Message----- From: Pasi Sarolahti [mailto:pasi.sarolahti@nokia.com] Sent: Monday, March 10, 2008 5:08 PM To: Murari Sridharan Cc: tcpm@ietf.org; mallman@icir.org Subject: Re: F-RTO and RFC 3517 interaction issues Hi Murari, Thanks for the careful reading! Clarification might indeed be in place. From quite early on when specifying the F-RTO algorithm we have thought it would be ok to allow fast recovery/SACK recovery immediately after detected spurious timeout, because then the TCP sender does not send the RTO retransmissions, and therefore the potential for RTO retransmissions triggering multiple fast retransmits should not exist (so the recover variable can be reset). For a case where spurious retransmission timeout follows the SACK recovery or fast recovery directly, this reasoning should be valid, do we agree? In case where spurious timeout happens during an earlier RTO recovery, there could be potential for false fast retransmits to happen, as described in the original NewReno draft. (RFC 3517 does not describe it in such detail, but I assume the motivation for the text you quote is same also there). On the other hand, the draft says that F-RTO SHOULD NOT be applied when an earlier SACK recovery is in progress, as I think it was in the example you presented. Do you think this note is sufficient, or should it be clarified somehow? - Pasi On Mar 10, 2008, at 13:05, ext Murari Sridharan wrote: > I am seeing an inconsistency between FRTO and RFC 3517. May be the > authors could clarify. > > F-RTO defines recovery as follows > > Set variable "recover" to > indicate the highest segment transmitted so far. > > RFC 3517 defines > "HighData" is the highest sequence number transmitted at a > given point. > > RFC 3517 clearly mandates that if RTO occurs during loss recovery > new recovery phase MUST not be initiated until the RecoveryPoint is > crossed. > "If an RTO occurs during loss recovery as specified in this > document, RecoveryPoint MUST be set to HighData. Further, the > new value of RecoveryPoint MUST be preserved and the loss > recovery algorithm outlined in this document MUST be terminated. > In addition, a new recovery phase (as described in section 5) > MUST NOT be initiated until HighACK is greater than or equal to > the new value of RecoveryPoint." Now FRTO spec seems to violate > the above rule with the following statementIf the algorithm exits > with SpuriousRecovery set to SPUR_TO, "recover" is set to > SND.UNA, thus allowing fast recovery on incoming duplicate > acknowledgments. This means that if we are in the middle of loss > recovery and a real timeout occurs we save the recovery point per > RFC 3517. At this point we continue with slow start and congestion > avoidance, now say we are still below the earlier recovery point > and a new timeout occurs. This time if the timeout is classified as > SPUR_TO, then RecoveryPoint is set to SndUNA, overwriting the older > value and a new recovery phase can begin, clearly violating RFC > 3517. ThanksMurari _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 11 11:13:36 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B858F3A6D98; Tue, 11 Mar 2008 11:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.145 X-Spam-Level: X-Spam-Status: No, score=-100.145 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 ukBLOd8xFksy; Tue, 11 Mar 2008 11:13:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382E93A6C47; Tue, 11 Mar 2008 11:13:31 -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 67E113A696F for ; Tue, 11 Mar 2008 11:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 vi04lFTRU3Bq for ; Tue, 11 Mar 2008 11:13:29 -0700 (PDT) Received: from mailer2.psc.edu (unknown [IPv6:2001:5e8:2:42:2e0:81ff:fe30:e898]) by core3.amsl.com (Postfix) with ESMTP id 27DAF3A691E for ; Tue, 11 Mar 2008 11:13:28 -0700 (PDT) Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer2.psc.edu (8.14.2/8.13.3) with ESMTP id m2BIB64w010783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Mar 2008 14:11:07 -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 m2BIB6RA028628 for ; Tue, 11 Mar 2008 14:11:06 -0400 Date: Tue, 11 Mar 2008 14:11:06 -0400 (EDT) From: Matt Mathis To: TCP Maintenance and Minor Extensions WG Message-ID: MIME-Version: 1.0 Subject: [tcpm] Example of 1323 window retraction problemPer my comments at the microphone at TCPM... 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-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 Consider a established TCP connection with WSCALE=7 (128 byte receiver window quantization), that is running with a very small windows because the receiver is bottlenecked and both ends are doing small reads and writes. Consider the ACKs coming back: seg.ack seg.win computed snd.win reviver's actual window 1000 2 1256 1300 sender writes 40 bytes and receiver ACKs: 1040 2 1296 1300 sender writes 5 more bytes and the receiver has a problem. Two choices: 1045 2 1301 1300 - BEYOND BUFFER 1045 1 1173 1300 - RETRACTED WINDOW This problems is completely general and can in principle happen any time the sender does a write which is smaller than the window scale quanta. In most stacks it is at least partially obscured when the window size is larger than some small number of segments because the stacks prefer to announce windows that are integral numbers of segments (rounded up to the next window quanta). This plus silly window suppression tends to cause less frequent, larger window updates. If the window was rounded down to a segment size there is more opportunity to advance it ("beyond buffer" case above) rather than retracting it. Thanks, --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. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 11 11:39:17 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2013A6D98; Tue, 11 Mar 2008 11:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.245 X-Spam-Level: X-Spam-Status: No, score=-100.245 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Nzsfh9BeU81s; Tue, 11 Mar 2008 11:39:13 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18AE3A69AC; Tue, 11 Mar 2008 11:39:13 -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 C2BFF3A691E for ; Tue, 11 Mar 2008 11:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 JRX6H7b3xJqh for ; Tue, 11 Mar 2008 11:39:12 -0700 (PDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) by core3.amsl.com (Postfix) with ESMTP id B0C583A69AC for ; Tue, 11 Mar 2008 11:39:11 -0700 (PDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id BE37B1ACED8 for ; Tue, 11 Mar 2008 14:36:51 -0400 (EDT) Date: Tue, 11 Mar 2008 14:36:51 -0400 From: Eric Rescorla To: tcpm@ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080311183651.BE37B1ACED8@kilo.rtfm.com> Subject: [tcpm] "The SYN trick" 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-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'd suggested using the ISNs as an implicit diversifier for a single master shared key. E.g., K_connection = HMAC(K_master, ISN_i, ISN_r) As Joe points out if you use ISNs as an implicit diversifier for a shared connection key. Obviously, you can't use the ISN sound in the SYN/ACK to key the initial SYN. The natural thing to do here is: - For the initial SYN use K_connection = HMAC(K_master, ISN_i, 0) - For subsequent packets use K_connection = HMAC(K_master, ISN_i, ISN_r) -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 11 12:58:00 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6611D28C47B; Tue, 11 Mar 2008 12:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.822 X-Spam-Level: X-Spam-Status: No, score=-100.822 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 KYAKTqk1m5gx; Tue, 11 Mar 2008 12:57:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D86B28C376; Tue, 11 Mar 2008 12:57: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 D2F9028C473 for ; Tue, 11 Mar 2008 12:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 N6l6E9AjSTL8 for ; Tue, 11 Mar 2008 12:57:50 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B863D28C42D for ; Tue, 11 Mar 2008 12:57:04 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 11 Mar 2008 12:54:45 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m2BJsixY032671; Tue, 11 Mar 2008 12:54:44 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2BJsWh2015867; Tue, 11 Mar 2008 19:54:44 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 15:54:43 -0400 Received: from [10.150.135.191] ([10.82.241.146]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 15:54:43 -0400 In-Reply-To: <20080311183651.BE37B1ACED8@kilo.rtfm.com> References: <20080311183651.BE37B1ACED8@kilo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <3FD0E4F5-8AA3-427E-BE87-EACAE62AA78D@cisco.com> From: Brian Weis Date: Tue, 11 Mar 2008 15:55:29 -0400 To: Eric Rescorla X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 11 Mar 2008 19:54:43.0497 (UTC) FILETIME=[C012D990:01C883B1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1487; t=1205265284; x=1206129284; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Re=3A=20[tcpm]=20=22The=20SYN=20trick=22 |Sender:=20; bh=zmb1nerIHbnUR2jspcjWUkTOKUtgJKwZsjfpLmyiiPk=; b=l/v0/kp2k7a8LCmztHfAqu+zn7LtYuV9P9MIDvZ+qDwCFRfgSEhwZh6tEi J65H+UedsWBr21ZpIosjJuGTROvzw59fm5UTrQbR/Fox5RiChOYG7CcTa1sc Bvgq36SirD; Authentication-Results: sj-dkim-4; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] "The SYN trick" 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-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 Eric, I like the simplicity of this approach. But using the ISNs to generate keys requires that the ISN values be generated from good random numbers (to avoid the generation of predicable keys). I think most systems today do happen to use a good RNG for generating the ISN, but there's no guarantee. This implies to me that ISN generation must be a service of the TCP- AO module, else the TCP-AO key generation process will not be guaranteed to generate good quality K_connection keys. I don't know if that's a requirement that can be made in the TCP-AO draft though. Thanks, Brian On Mar 11, 2008, at 2:36 PM, Eric Rescorla wrote: > I'd suggested using the ISNs as an implicit diversifier for > a single master shared key. > > E.g., > > K_connection = HMAC(K_master, ISN_i, ISN_r) > > As Joe points out if you use ISNs as an implicit diversifier > for a shared connection key. Obviously, you can't use the > ISN sound in the SYN/ACK to key the initial SYN. The natural > thing to do here is: > > - For the initial SYN use K_connection = HMAC(K_master, ISN_i, 0) > - For subsequent packets use K_connection = HMAC(K_master, ISN_i, > ISN_r) > > -Ekr > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 11 13:29:11 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A08128C652; Tue, 11 Mar 2008 13:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.282 X-Spam-Level: X-Spam-Status: No, score=-100.282 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 TNoIK2ABCr0Q; Tue, 11 Mar 2008 13:29:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D925628C4F3; Tue, 11 Mar 2008 13:28:44 -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 CC6173A682C for ; Tue, 11 Mar 2008 13:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 jS-pv9d8QQuh for ; Tue, 11 Mar 2008 13:28:43 -0700 (PDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) by core3.amsl.com (Postfix) with ESMTP id C0A9F28C4FF for ; Tue, 11 Mar 2008 13:27:20 -0700 (PDT) Received: from dhcp-11ec.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id F245A1AD5EF; Tue, 11 Mar 2008 16:25:00 -0400 (EDT) Date: Tue, 11 Mar 2008 16:25:00 -0400 From: Eric Rescorla To: Brian Weis In-Reply-To: <3FD0E4F5-8AA3-427E-BE87-EACAE62AA78D@cisco.com> References: <20080311183651.BE37B1ACED8@kilo.rtfm.com> <3FD0E4F5-8AA3-427E-BE87-EACAE62AA78D@cisco.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080311202500.F245A1AD5EF@kilo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] "The SYN trick" 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-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 At Tue, 11 Mar 2008 15:55:29 -0400, Brian Weis wrote: > > Hi Eric, > > I like the simplicity of this approach. But using the ISNs to > generate keys requires that the ISN values be generated from good > random numbers (to avoid the generation of predicable keys). I think > most systems today do happen to use a good RNG for generating the > ISN, but there's no guarantee. Actually, this isn't correct, because we're assuming that we have an initial strong key and we're just using the ISNs for diversity. S 6.1.2 of draft-rescorla-tcp-auth-arch-00 goes into this in more detail: A substantial amount of resistance to inter-connection cut-and-paste attacks can be achieved by exploiting connection information other than the host/port quartet. For instance, one could start with a static key and use the TCP ISNs to produce a unique per-connection key: K_connection = HMAC(K_static, ISN_client || ISN_server) If we treat ISNs as random variates (note: this does not require cryptographic randomness, just low probability of collisions) then there are 2^{64} equally probable ISN combinations between any pair of hosts, which implies 2^{64} potential keys (even if we ignore the host/port quartet), so the chance of two connection keys colliding becomes acceptably low: on average there will be a collision after 2^{32} connections. If the host/port quartet is included, then collisions become even less probable. Note: the ISNs are being used here serve the same role as nonces in standard cryptographic protocols (e.g., the ClientRandom and ServerRandom in TLS). Therefore, the security model explicitly assumes that they are public information. Thus, the sequence number predictability issues described on [RFC1948] do not impact the security of the system. Only nonce uniqueness is required. This scheme has very similar security properties to the scheme described in Section 6.1.1, including having a compatible key management interface. Unlike static keys, however, there is a significant amount of resistance to inter-connection cut-and-paste attacks because each connection with high probability uses a unique key. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 11 14:15:22 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D6228C243; Tue, 11 Mar 2008 14:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.997 X-Spam-Level: X-Spam-Status: No, score=-100.997 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 stKI23Y1XBAe; Tue, 11 Mar 2008 14:15:21 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDB328C51A; Tue, 11 Mar 2008 14:15:18 -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 0E1E628C51A for ; Tue, 11 Mar 2008 14:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 rwXsc73rBgMy for ; Tue, 11 Mar 2008 14:15:17 -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 5498128C21B for ; Tue, 11 Mar 2008 14:15:14 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 11 Mar 2008 14:12:55 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2BLCt2u020528; Tue, 11 Mar 2008 14:12:55 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2BLChgq005777; Tue, 11 Mar 2008 21:12:54 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 17:12:46 -0400 Received: from [10.150.135.191] ([10.82.241.146]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 17:12:45 -0400 In-Reply-To: <20080311202500.F245A1AD5EF@kilo.rtfm.com> References: <20080311183651.BE37B1ACED8@kilo.rtfm.com> <3FD0E4F5-8AA3-427E-BE87-EACAE62AA78D@cisco.com> <20080311202500.F245A1AD5EF@kilo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Brian Weis Date: Tue, 11 Mar 2008 17:13:31 -0400 To: Eric Rescorla X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 11 Mar 2008 21:12:45.0838 (UTC) FILETIME=[A6F762E0:01C883BC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3112; t=1205269975; x=1206133975; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Re=3A=20[tcpm]=20=22The=20SYN=20trick=22 |Sender:=20; bh=yHNYy2FNey8YtP7ZEqqnEm9RUqXmk1q7r0hSKTBeyzo=; b=ZFp1vqK5XJiN5cbJIyMeqknNBRuAuT+xv3TkpSpVbUTNSz3yEVaS2xRF9Z 5vW06mfFjVUlZ3dHuqBQg3HueqJnXRWLn4KsRJTeQzrc4Xq4t7yZDVc4D9MG EBPISmQ/QdHvV9WEXzkjlgzqKf+/0Q9ArEwyCdeQz+glrYPIURZiM=; Authentication-Results: sj-dkim-1; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] "The SYN trick" 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-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 Eric, On Mar 11, 2008, at 4:25 PM, Eric Rescorla wrote: > At Tue, 11 Mar 2008 15:55:29 -0400, > Brian Weis wrote: >> >> Hi Eric, >> >> I like the simplicity of this approach. But using the ISNs to >> generate keys requires that the ISN values be generated from good >> random numbers (to avoid the generation of predicable keys). I think >> most systems today do happen to use a good RNG for generating the >> ISN, but there's no guarantee. > > Actually, this isn't correct, because we're assuming that we have > an initial strong key and we're just using the ISNs for diversity. > S 6.1.2 of draft-rescorla-tcp-auth-arch-00 goes into this in > more detail: > > A substantial amount of resistance to inter-connection cut-and- > paste > attacks can be achieved by exploiting connection information other > than the host/port quartet. For instance, one could start with a > static key and use the TCP ISNs to produce a unique per-connection > key: > > K_connection = HMAC(K_static, ISN_client || ISN_server) > > If we treat ISNs as random variates (note: this does not require > cryptographic randomness, just low probability of collisions) then > there are 2^{64} equally probable ISN combinations between any pair > of hosts, which implies 2^{64} potential keys (even if we ignore > the > host/port quartet), so the chance of two connection keys colliding > becomes acceptably low: on average there will be a collision after > 2^{32} connections. If the host/port quartet is included, then > collisions become even less probable. > > Note: the ISNs are being used here serve the same role as > nonces > in standard cryptographic protocols (e.g., the ClientRandom and > ServerRandom in TLS). Therefore, the security model explicitly > assumes that they are public information. Thus, the sequence > number predictability issues described on [RFC1948] do not > impact > the security of the system. Only nonce uniqueness is required. Treating the ISNs as nonces makes a lot of sense. But that reminds me that NIST is preparing a draft document (for release one of these days) describing acceptable KDFs based on a secret key. I've been advised that it will recommend including entity identities in the derivation, to tie key derivation to a particular session. So something like the following method might be better: K_connection = HMAC(K_master, ISN_i, ISN_r, IP_address_i, IP_address_r, port_i, port_r) Thanks, Brian > This scheme has very similar security properties to the scheme > described in Section 6.1.1, including having a compatible key > management interface. Unlike static keys, however, there is a > significant amount of resistance to inter-connection cut-and-paste > attacks because each connection with high probability uses a unique > key. > > -Ekr > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 11 15:39:57 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21A5828C2C9; Tue, 11 Mar 2008 15:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.31 X-Spam-Level: X-Spam-Status: No, score=-100.31 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 9U9a4vNe3Xf8; Tue, 11 Mar 2008 15:39:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD4028C3C1; Tue, 11 Mar 2008 15:39:53 -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 6E78828C3C1 for ; Tue, 11 Mar 2008 15:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 tursaq6s+XNi for ; Tue, 11 Mar 2008 15:39:50 -0700 (PDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) by core3.amsl.com (Postfix) with ESMTP id 8F0BE28C2E1 for ; Tue, 11 Mar 2008 15:39:50 -0700 (PDT) Received: from dhcp-11ec.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id C79B71AD8B0; Tue, 11 Mar 2008 18:37:30 -0400 (EDT) Date: Tue, 11 Mar 2008 18:37:30 -0400 From: Eric Rescorla To: Brian Weis In-Reply-To: References: <20080311183651.BE37B1ACED8@kilo.rtfm.com> <3FD0E4F5-8AA3-427E-BE87-EACAE62AA78D@cisco.com> <20080311202500.F245A1AD5EF@kilo.rtfm.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080311223730.C79B71AD8B0@kilo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] "The SYN trick" 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-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 At Tue, 11 Mar 2008 17:13:31 -0400, Brian Weis wrote: > On Mar 11, 2008, at 4:25 PM, Eric Rescorla wrote: > > > At Tue, 11 Mar 2008 15:55:29 -0400, > > Brian Weis wrote: > >> > >> Hi Eric, > >> > >> I like the simplicity of this approach. But using the ISNs to > >> generate keys requires that the ISN values be generated from good > >> random numbers (to avoid the generation of predicable keys). I think > >> most systems today do happen to use a good RNG for generating the > >> ISN, but there's no guarantee. > > > > Actually, this isn't correct, because we're assuming that we have > > an initial strong key and we're just using the ISNs for diversity. > > S 6.1.2 of draft-rescorla-tcp-auth-arch-00 goes into this in > > more detail: > > > > A substantial amount of resistance to inter-connection cut-and- > > paste > > attacks can be achieved by exploiting connection information other > > than the host/port quartet. For instance, one could start with a > > static key and use the TCP ISNs to produce a unique per-connection > > key: > > > > K_connection = HMAC(K_static, ISN_client || ISN_server) > > > > If we treat ISNs as random variates (note: this does not require > > cryptographic randomness, just low probability of collisions) then > > there are 2^{64} equally probable ISN combinations between any pair > > of hosts, which implies 2^{64} potential keys (even if we ignore > > the > > host/port quartet), so the chance of two connection keys colliding > > becomes acceptably low: on average there will be a collision after > > 2^{32} connections. If the host/port quartet is included, then > > collisions become even less probable. > > > > Note: the ISNs are being used here serve the same role as > > nonces > > in standard cryptographic protocols (e.g., the ClientRandom and > > ServerRandom in TLS). Therefore, the security model explicitly > > assumes that they are public information. Thus, the sequence > > number predictability issues described on [RFC1948] do not > > impact > > the security of the system. Only nonce uniqueness is required. > > Treating the ISNs as nonces makes a lot of sense. > > But that reminds me that NIST is preparing a draft document (for > release one of these days) describing acceptable KDFs based on a > secret key. I've been advised that it will recommend including entity > identities in the derivation, to tie key derivation to a particular > session. So something like the following method might be better: > > K_connection = HMAC(K_master, ISN_i, ISN_r, IP_address_i, > IP_address_r, port_i, port_r) I totally agree. I have some cryptographic argument that this isn't necessary since these values get included in the MAC anyway, but I agree that this is more in line with standard practice. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 12 07:58:51 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16A3F28C7B7; Wed, 12 Mar 2008 07:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.934 X-Spam-Level: X-Spam-Status: No, score=-102.934 tagged_above=-999 required=5 tests=[AWL=-2.496, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 9Q0en6QJuSt8; Wed, 12 Mar 2008 07:58:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D77728C7C9; Wed, 12 Mar 2008 07:58: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 A1BC528C7FB for ; Wed, 12 Mar 2008 07:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 oUQmqIc3wURH for ; Wed, 12 Mar 2008 07:58:36 -0700 (PDT) Received: from smtp.uibk.ac.at (lmr1.uibk.ac.at [138.232.1.142]) by core3.amsl.com (Postfix) with ESMTP id 75D5528C7C5 for ; Wed, 12 Mar 2008 07:58:26 -0700 (PDT) Received: from [138.232.65.105] (pc105-c703.uibk.ac.at [138.232.65.105] michael.welzl@uibk.ac.at) (authenticated bits=0) by smtp.uibk.ac.at (8.13.8/8.13.8/F1) with ESMTP id m2CEtx8O008387 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 12 Mar 2008 15:55:59 +0100 From: Michael Welzl To: Joe Touch In-Reply-To: <45C0CE79.4040303@isi.edu> References: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at> <20070131164323.GD16985@elb.elitists.net> <45C0CE79.4040303@isi.edu> Organization: University of Innsbruck Date: Wed, 12 Mar 2008 15:55:59 +0100 Message-Id: <1205333759.3719.109.camel@pc105-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Scanned-By: MIMEDefang 2.61 at uibk.ac.at on 138.232.1.140 Cc: tcpm@ietf.org, iccrg@cs.ucl.ac.uk Subject: Re: [tcpm] Separate header checksums and WiFi 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-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 all, [ Answering an email from January 2007 (my, my, how time flies :-( ), and including ICCRG because I recently mentioned this study there, so it might be of interest to them too ] We finally did that: Michael Welzl, Mattia Rossi, Andrea Fumagalli, Marco Tacca, "TCP/IP over IEEE 802.11b WLAN: the Challenge of Harnessing Known-Corrupt Data", accepted for publication, IEEE ICC 2008 (International Conference on Communications), 19-23 May 2008, Beijing, China. Available from http://www.welzl.at/research/projects/corruption/index.html (until somebody tells me that I misread the legal bits and am not allowed to do so) Cheers, Michael On Wed, 2007-01-31 at 09:14 -0800, Joe Touch wrote: > Beyond what Ethan is suggesting, this is useful to write up more fully > and publish, e.g., at Globecom or ICC. Negative results, as Ethan notes, > are critical to the community as a whole. > > Joe > > Ethan Blanton wrote: > > Michael Welzl spake unto us the following wisdom: > >> I figured that the only convincing way to prove him > >> wrong is to actually do a real-life test. I did, and > >> proved him right :) that is, disabling checksums for > >> parts of packets doesn't yield much of a benefit in > >> WiFi networks, where it seems that frames are delivered > >> in an all-or-nothing fashion. > > > > I have to applaud this move. All too often we only talk about the > > things we did that *worked*, and the same questions about things that > > any number of people would tell you doesn't work come up over and > > over. For this particular topic, there is now a citation, so the next > > guy won't have to go try it himself. Thank you. > > > > Ethan > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www1.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 12 19:51:04 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2437F28C2EC; Wed, 12 Mar 2008 19:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.46 X-Spam-Level: X-Spam-Status: No, score=-100.46 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 3TcvfRz6hwMy; Wed, 12 Mar 2008 19:51:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D6128C769; Wed, 12 Mar 2008 19:51:03 -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 D8B0A28C2EC for ; Wed, 12 Mar 2008 19:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 8Bz+nxo17W8X for ; Wed, 12 Mar 2008 19:51:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4E5F528C4B9 for ; Wed, 12 Mar 2008 19:51:00 -0700 (PDT) Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2D2mGrS005572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Mar 2008 19:48:18 -0700 (PDT) Message-ID: <47D895C5.8080406@isi.edu> Date: Wed, 12 Mar 2008 19:47:33 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Michael Welzl References: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at> <20070131164323.GD16985@elb.elitists.net> <45C0CE79.4040303@isi.edu> <1205333759.3719.109.camel@pc105-c703.uibk.ac.at> In-Reply-To: <1205333759.3719.109.camel@pc105-c703.uibk.ac.at> 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, iccrg@cs.ucl.ac.uk Subject: Re: [tcpm] Separate header checksums and WiFi 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-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0617258240==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0617258240== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB8F9CA88F13A8138985D16C5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB8F9CA88F13A8138985D16C5 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Very nice. Congrats! Joe Michael Welzl wrote: > Hi all, >=20 > [ Answering an email from January 2007 (my, my, how time flies :-( ),= > and including ICCRG because I recently mentioned this study there, > so it might be of interest to them too ] >=20 > We finally did that: >=20 > Michael Welzl, Mattia Rossi, Andrea Fumagalli, Marco Tacca, "TCP/IP ove= r > IEEE 802.11b WLAN: the Challenge of Harnessing Known-Corrupt Data", > accepted for publication, IEEE ICC 2008 (International Conference on > Communications), 19-23 May 2008, Beijing, China. >=20 > Available from > http://www.welzl.at/research/projects/corruption/index.html > (until somebody tells me that I misread the legal bits and > am not allowed to do so) >=20 > Cheers, > Michael >=20 >=20 >=20 > On Wed, 2007-01-31 at 09:14 -0800, Joe Touch wrote: >> Beyond what Ethan is suggesting, this is useful to write up more fully= >> and publish, e.g., at Globecom or ICC. Negative results, as Ethan note= s, >> are critical to the community as a whole. >> >> Joe >> >> Ethan Blanton wrote: >>> Michael Welzl spake unto us the following wisdom: >>>> I figured that the only convincing way to prove him >>>> wrong is to actually do a real-life test. I did, and >>>> proved him right :) that is, disabling checksums for >>>> parts of packets doesn't yield much of a benefit in >>>> WiFi networks, where it seems that frames are delivered >>>> in an all-or-nothing fashion. >>> I have to applaud this move. All too often we only talk about the >>> things we did that *worked*, and the same questions about things that= >>> any number of people would tell you doesn't work come up over and >>> over. For this particular topic, there is now a citation, so the nex= t >>> guy won't have to go try it himself. Thank you. >>> >>> Ethan >>> >>> >>> >>> ---------------------------------------------------------------------= --- >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/tcpm >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm --------------enigB8F9CA88F13A8138985D16C5 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 iD8DBQFH2JXFE5f5cImnZrsRAoooAJ0Soxr+re/xaLa+mFlN79Omwh55FgCguqYy T+RWV+olnv+S2/ooBKd1YEA= =6j9w -----END PGP SIGNATURE----- --------------enigB8F9CA88F13A8138985D16C5-- --===============0617258240== 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 --===============0617258240==-- From tcpm-bounces@ietf.org Thu Mar 13 13:32:53 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E70E3A6E4F; Thu, 13 Mar 2008 13:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.925 X-Spam-Level: X-Spam-Status: No, score=-100.925 tagged_above=-999 required=5 tests=[AWL=-1.088, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 WlVZ69Sji6gs; Thu, 13 Mar 2008 13:32:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43D963A6816; Thu, 13 Mar 2008 13:32:52 -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 127523A6A28 for ; Thu, 13 Mar 2008 13:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 lIA9EhzTjLa6 for ; Thu, 13 Mar 2008 13:32:49 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 467E03A69D5 for ; Thu, 13 Mar 2008 13:32:21 -0700 (PDT) Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.54.46.185) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 13 Mar 2008 13:30:14 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.54.46.185]) with mapi; Thu, 13 Mar 2008 13:30:03 -0700 From: Murari Sridharan To: Murari Sridharan , Pasi Sarolahti Date: Thu, 13 Mar 2008 13:30:02 -0700 Thread-Topic: F-RTO and RFC 3517 interaction issues Thread-Index: AciDDBZURGBdrNFmSbaMa3csR5zchgAf/jgwAAJPPHAAbNMzcA== Message-ID: References: <7D419A49-15F9-450F-B51B-C217123475F7@nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] F-RTO and RFC 3517 interaction issues 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-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 Pasi any updates on this? I'd like to try out a fix to address this issue. -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Murari Sridharan Sent: Tuesday, March 11, 2008 9:48 AM To: Pasi Sarolahti Cc: tcpm@ietf.org; mallman@icir.org Subject: Re: [tcpm] F-RTO and RFC 3517 interaction issues The main issue I see is that without maintaining extra state how do you know which situation you are in? I think the draft should clarify how exactly this should be done to avoid incorrect implementations. Here are the cases as I see it broadly there are two cases but its really 3 sub-cases. The cases are as FRTO sees the TCP state when it is about to classify a timeout. a) This is the simplest case when timeout has happened without any prior recovery attempt. Setting Recover = SndUna works fine here. b) Recovery in progress. Fast retransmit is triggered, 3517 may be active, now the timeout happens. If SPUR_TO, Recover = SndUna is ok for the reasons you outline below. c) Recovery in progress like (b), timeout happens but this is a real timeout. Now next phase starts with valid Recover value based on 3517. Another timeout happens before Recover is crossed, now *without any additional state* there is no way to differentiate this from case (b). There should be some additional state associated with the value stored in Recover which is if FRTO declared a real timeout. Now you can say only reset Recover = SndUna only if Recover is not associated with a real timeout. If we want to avoid implementation bugs we need to be prescriptive here so it may not be enough to say " On the other hand, the draft says that F-RTO SHOULD NOT be applied when an earlier SACK recovery is in progress" Because it doesn't clarify how case (b) is different from (c). In both cases an earlier SACK recovery is in progress. Hope this helps. Murari -----Original Message----- From: Pasi Sarolahti [mailto:pasi.sarolahti@nokia.com] Sent: Monday, March 10, 2008 5:08 PM To: Murari Sridharan Cc: tcpm@ietf.org; mallman@icir.org Subject: Re: F-RTO and RFC 3517 interaction issues Hi Murari, Thanks for the careful reading! Clarification might indeed be in place. From quite early on when specifying the F-RTO algorithm we have thought it would be ok to allow fast recovery/SACK recovery immediately after detected spurious timeout, because then the TCP sender does not send the RTO retransmissions, and therefore the potential for RTO retransmissions triggering multiple fast retransmits should not exist (so the recover variable can be reset). For a case where spurious retransmission timeout follows the SACK recovery or fast recovery directly, this reasoning should be valid, do we agree? In case where spurious timeout happens during an earlier RTO recovery, there could be potential for false fast retransmits to happen, as described in the original NewReno draft. (RFC 3517 does not describe it in such detail, but I assume the motivation for the text you quote is same also there). On the other hand, the draft says that F-RTO SHOULD NOT be applied when an earlier SACK recovery is in progress, as I think it was in the example you presented. Do you think this note is sufficient, or should it be clarified somehow? - Pasi On Mar 10, 2008, at 13:05, ext Murari Sridharan wrote: > I am seeing an inconsistency between FRTO and RFC 3517. May be the > authors could clarify. > > F-RTO defines recovery as follows > > Set variable "recover" to > indicate the highest segment transmitted so far. > > RFC 3517 defines > "HighData" is the highest sequence number transmitted at a > given point. > > RFC 3517 clearly mandates that if RTO occurs during loss recovery > new recovery phase MUST not be initiated until the RecoveryPoint is > crossed. > "If an RTO occurs during loss recovery as specified in this > document, RecoveryPoint MUST be set to HighData. Further, the > new value of RecoveryPoint MUST be preserved and the loss > recovery algorithm outlined in this document MUST be terminated. > In addition, a new recovery phase (as described in section 5) > MUST NOT be initiated until HighACK is greater than or equal to > the new value of RecoveryPoint." Now FRTO spec seems to violate > the above rule with the following statementIf the algorithm exits > with SpuriousRecovery set to SPUR_TO, "recover" is set to > SND.UNA, thus allowing fast recovery on incoming duplicate > acknowledgments. This means that if we are in the middle of loss > recovery and a real timeout occurs we save the recovery point per > RFC 3517. At this point we continue with slow start and congestion > avoidance, now say we are still below the earlier recovery point > and a new timeout occurs. This time if the timeout is classified as > SPUR_TO, then RecoveryPoint is set to SndUNA, overwriting the older > value and a new recovery phase can begin, clearly violating RFC > 3517. ThanksMurari _______________________________________________ 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 Thu Mar 13 16:39:15 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C11E28C7D3; Thu, 13 Mar 2008 16:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.836 X-Spam-Level: X-Spam-Status: No, score=-100.836 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 unkJt5+ahRNA; Thu, 13 Mar 2008 16:39:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F87C28C2ED; Thu, 13 Mar 2008 16:39: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 B3FD728C1EE for ; Thu, 13 Mar 2008 16:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 dfl4Ny1iacYM for ; Thu, 13 Mar 2008 16:39:11 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id 3E1763A6CD5 for ; Thu, 13 Mar 2008 16:39:11 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so1097315and.122 for ; Thu, 13 Mar 2008 16:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=PWRocUPo5kp/KXZd4uv/bvdHJSwuleEybT0Wlw1vhtM=; b=SRpdW/RJ4MfS1B0J9MBLfuUb1QXhAF/fvAi1k2opwt9Dk8HEURqkuQ5xhJEMgLICJ3ogy+a/niPFv5BIBmhSfj0lJtSznv7O65ceg/S9aXSav8ujKLVRnnL6Jt6tY4fYoaJuIdFtZr0LmcavuPj+BEeu/hKKFvYeeTiizUyUOtw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=uNX1qCMNqs/A28CdwRzltGDFguGsNTwbfos195MRjo9E0ygCdzVMBac87uONXJXhyTF91Bu2Mgw7ND8UP98dE1cdn1WxAF65WGAlbPnnMOtLlQYkUZYLSJUgq8zXNo7xbnpRhl5EOI10hH2tcivMRkPNbjafFnJ7eDdPDeLE4iY= Received: by 10.100.144.18 with SMTP id r18mr20876294and.112.1205451413421; Thu, 13 Mar 2008 16:36:53 -0700 (PDT) Received: from ?130.129.84.254? ( [130.129.84.254]) by mx.google.com with ESMTPS id c28sm26844525anc.32.2008.03.13.16.36.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Mar 2008 16:36:53 -0700 (PDT) Message-Id: <0A9BAFBD-68F2-4EC8-AC86-009905F9F01E@nokia.com> From: Lars Eggert To: mallman@icir.org In-Reply-To: <20080212040134.0C2093AEC52@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 13 Mar 2008 19:36:51 -0400 References: <20080212040134.0C2093AEC52@lawyers.icir.org> X-Mailer: Apple Mail (2.919.2) Cc: Aleksandar Kuzmanovic , tcpm , Ted Faber , Amit Mondal , "K. K. Ramakrishnan" Subject: [tcpm] AD review: draft-ietf-tcpm-ecnsyn-05 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-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 did my AD review for draft-ietf-tcpm-ecnsyn-05. Basically, it's good to go to IETF last call. There are a few minor suggestions and nits below. I'd suggest that we go to IETF Last Call and fix these together with any other comments that we receive during the comment period. (Alternatively, the authors could do another revisions now. Up to you, just let me know which way you're going, so I can initiate the last call or wait.) Thanks, Lars INTRODUCTION, paragraph 13: > This document is intended to update RFC 3168. s/is intended to update/updates/ and also add an "Updates: 3168" header to the boilerplate. Section 3., paragraph 0: > 3. Proposal s/Proposal/Specification/ (or Recommendation, but because the text below "only" changes a MUST NOT to a MAY, that may be too strong) Section 3., paragraph 3: > Assume that TCP node A transmits to TCP node B an ECN-setup SYN > packet, indicating willingness to use ECN for this connection. As > specified by RFC 3168, if TCP node B is willing to use ECN, node B > responds with an ECN-setup SYN-ACK packet. Suggestion: Start a new section before this paragraph, because the remainder of the original section is more of a description of the effects of the change, rather than continuing the specification. Section 4., paragraph 0: > 4. Discussion Nit: Section would be more readable if "Motivation:", "Flooding attacks:" etc. became real, numbered subsections. (Same in Section 7.) Section 6.2., paragraph 2: > Simulations comparing the performance with Standard ECN (without ECN- > marked SYN/ACK packets), ECN+ with NoWaiting, and ECN+ with Waiting > show little difference, in terms of aggregate congestion, between > ECN+ with NoWaiting and ECN+ with Waiting. The details are given in > Appendix A below. Our conclusions are that ECN+ with NoWaiting is > perfectly safe, and there are no congestion-related reasons for > preferring ECN+ with Waiting over ECN+ with NoWaiting. That is, > there is no need for the TCP end-node to wait a round-trip time > before sending a data packet after receiving an acknowledgement of an > ECN-marked SYN/ACK packet. That recommendation (that NoWaiting is safe and Waiting therefore need not be preferred) should also briefly be discussed in Section 4 where the approaches are first described. Or, if NoWaiting is preferred, maybe the Waiting alternative should be moved out of Section 4 and into another Section (this one?) Section 8., paragraph 2: > Future work will address the more general question of adding ECN- > Capability to relevant handshake packets in other protocols that use > retransmission-based reliability in their setup phase (e.g., SCTP, > DCCP, HIP, and the like). That work doesn't seem to be happening, so I would suggest to remove this section. Section 100, paragraph 32: > Capabililty for SYN/ACK packets, it is possible that the ECN-Capable Nit: s/Capabililty/Capability/ Section 100, paragraph 46: > [ECN-SYN] ECN-SYN web page with simulation scripts, URL to be added. URL needs to be added now. Section 100, paragraph 60: > [SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also > Might also want to refer to RFC 4987. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 13 18:38:14 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEADC28C21E; Thu, 13 Mar 2008 18:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.714 X-Spam-Level: X-Spam-Status: No, score=-100.714 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 a6SIoVd8QU6o; Thu, 13 Mar 2008 18:38:13 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29463A6942; Thu, 13 Mar 2008 18:38:12 -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 EA4FE3A6908 for ; Thu, 13 Mar 2008 18:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 zlGtMBzPU1A5 for ; Thu, 13 Mar 2008 18:38:11 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B20323A6800 for ; Thu, 13 Mar 2008 18:38:10 -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 m2E1ZFCu022381; Fri, 14 Mar 2008 03:35:42 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 03:35:40 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 03:35:40 +0200 Received: from [10.150.134.0] ([10.241.59.27]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 03:35:40 +0200 In-Reply-To: References: <7D419A49-15F9-450F-B51B-C217123475F7@nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <58A857FF-A752-474C-9CD1-2F99506DDA10@nokia.com> From: Pasi Sarolahti Date: Thu, 13 Mar 2008 21:35:34 -0400 To: "ext Murari Sridharan" X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 14 Mar 2008 01:35:40.0521 (UTC) FILETIME=[B63C7D90:01C88573] X-Nokia-AV: Clean Cc: "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] F-RTO and RFC 3517 interaction issues 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-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 Murari, Yes, I think your reasoning below is basically right, except that I think case (b) should not happen, because F-RTO is not allowed during earlier recovery (I had this mistake also in my earlier mail). We'll revise the draft ASAP, but before that I'd like to think a bit more about what is the minimal state needed at the sender, and if it was possible to do something without adding extra state or too much extra complexity. I wonder if rephrasing the "This algorithm SHOULD NOT be applied if the TCP sender is already in SACK loss recovery when retransmission timeout occurs." condition in the following way would help: when timeout occurs: if (RecoveryPoint <= snd.una) then execute F-RTO else follow normal RTO recovery procedure directly (e.g., set RecoveryPoint = HighData) in addition setting RecoveryPoint = HighData in F-RTO algorithm should be postponed to step 2 to allow F-RTO for cases where delay causes multiple consecutive timeouts. I need to think about this a bit more, but wouldn't this solve the case (c) below? It would also prevent F-RTO during recovery from earlier genuine timeout, but I think this should be ok. What do you think? Does this seem like a way forward? - Pasi On Mar 13, 2008, at 16:30, ext Murari Sridharan wrote: > Pasi any updates on this? I'd like to try out a fix to address this > issue. > > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Murari Sridharan > Sent: Tuesday, March 11, 2008 9:48 AM > To: Pasi Sarolahti > Cc: tcpm@ietf.org; mallman@icir.org > Subject: Re: [tcpm] F-RTO and RFC 3517 interaction issues > > The main issue I see is that without maintaining extra state how do > you know which situation you are in? I think the draft should > clarify how exactly this should be done to avoid incorrect > implementations. Here are the cases as I see it broadly there are > two cases but its really 3 sub-cases. The cases are as FRTO sees > the TCP state when it is about to classify a timeout. > > a) This is the simplest case when timeout has happened without any > prior recovery attempt. Setting Recover = SndUna works fine here. > b) Recovery in progress. Fast retransmit is triggered, 3517 may be > active, now the timeout happens. If SPUR_TO, Recover = SndUna is ok > for the reasons you outline below. > c) Recovery in progress like (b), timeout happens but this is a > real timeout. Now next phase starts with valid Recover value based > on 3517. Another timeout happens before Recover is crossed, now > *without any additional state* there is no way to differentiate > this from case (b). > > There should be some additional state associated with the value > stored in Recover which is if FRTO declared a real timeout. Now you > can say only reset Recover = SndUna only if Recover is not > associated with a real timeout. If we want to avoid implementation > bugs we need to be prescriptive here so it may not be enough to say > " On the other hand, the draft says > that F-RTO SHOULD NOT be applied when an earlier SACK recovery is in > progress" Because it doesn't clarify how case (b) is different from > (c). In both cases an earlier SACK recovery is in progress. > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 14 11:26:30 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587C23A6DB9; Fri, 14 Mar 2008 11:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.047 X-Spam-Level: X-Spam-Status: No, score=-101.047 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 ZXNQg278jCDS; Fri, 14 Mar 2008 11:26:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377273A6ABD; Fri, 14 Mar 2008 11:26:29 -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 447C73A6B61 for ; Fri, 14 Mar 2008 11:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 iummQ0BNVdGR for ; Fri, 14 Mar 2008 11:26:27 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 2DC523A67CF for ; Fri, 14 Mar 2008 11:26:27 -0700 (PDT) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 14 Mar 2008 11:24:23 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.88.97]) with mapi; Fri, 14 Mar 2008 11:24:10 -0700 From: Murari Sridharan To: Pasi Sarolahti Date: Fri, 14 Mar 2008 11:24:09 -0700 Thread-Topic: F-RTO and RFC 3517 interaction issues Thread-Index: AciFc8DVKl3ffsaJSWecjnHXq+bsYgAi1DRw Message-ID: References: <7D419A49-15F9-450F-B51B-C217123475F7@nokia.com> <58A857FF-A752-474C-9CD1-2F99506DDA10@nokia.com> In-Reply-To: <58A857FF-A752-474C-9CD1-2F99506DDA10@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] F-RTO and RFC 3517 interaction issues 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-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 agree that this approach would solve the problem I mentioned below but this will prevent FRTO recovery for case (b) isn't that too restrictive? Would it negate some of the benefits of FRTO? The reason I ask is that packet reordering may be very common and we might very well be in recovery when a timeout happens. The case is that we see some dupacks indicating out of order packets may be during some mobility handoff, we enter recovery but the delay spike causes a timeout. This timeout is possibly spurious. I think the question really is how often does recovery precede a spurious timeout in the real world? Do you have any data from your testing. I know you discuss some of this in the appendix section of the draft as possible extensions, however it may be simple to fix if we maintain the extra bit that says that a real timeout occurred during earlier loss recovery so FRTO cannot begin till the recovery point is crossed. -----Original Message----- From: Pasi Sarolahti [mailto:pasi.sarolahti@nokia.com] Sent: Thursday, March 13, 2008 6:36 PM To: Murari Sridharan Cc: tcpm@ietf.org; mallman@icir.org Subject: Re: F-RTO and RFC 3517 interaction issues Hi Murari, Yes, I think your reasoning below is basically right, except that I think case (b) should not happen, because F-RTO is not allowed during earlier recovery (I had this mistake also in my earlier mail). We'll revise the draft ASAP, but before that I'd like to think a bit more about what is the minimal state needed at the sender, and if it was possible to do something without adding extra state or too much extra complexity. I wonder if rephrasing the "This algorithm SHOULD NOT be applied if the TCP sender is already in SACK loss recovery when retransmission timeout occurs." condition in the following way would help: when timeout occurs: if (RecoveryPoint <= snd.una) then execute F-RTO else follow normal RTO recovery procedure directly (e.g., set RecoveryPoint = HighData) in addition setting RecoveryPoint = HighData in F-RTO algorithm should be postponed to step 2 to allow F-RTO for cases where delay causes multiple consecutive timeouts. I need to think about this a bit more, but wouldn't this solve the case (c) below? It would also prevent F-RTO during recovery from earlier genuine timeout, but I think this should be ok. What do you think? Does this seem like a way forward? - Pasi On Mar 13, 2008, at 16:30, ext Murari Sridharan wrote: > Pasi any updates on this? I'd like to try out a fix to address this > issue. > > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Murari Sridharan > Sent: Tuesday, March 11, 2008 9:48 AM > To: Pasi Sarolahti > Cc: tcpm@ietf.org; mallman@icir.org > Subject: Re: [tcpm] F-RTO and RFC 3517 interaction issues > > The main issue I see is that without maintaining extra state how do > you know which situation you are in? I think the draft should > clarify how exactly this should be done to avoid incorrect > implementations. Here are the cases as I see it broadly there are > two cases but its really 3 sub-cases. The cases are as FRTO sees > the TCP state when it is about to classify a timeout. > > a) This is the simplest case when timeout has happened without any > prior recovery attempt. Setting Recover = SndUna works fine here. > b) Recovery in progress. Fast retransmit is triggered, 3517 may be > active, now the timeout happens. If SPUR_TO, Recover = SndUna is ok > for the reasons you outline below. > c) Recovery in progress like (b), timeout happens but this is a > real timeout. Now next phase starts with valid Recover value based > on 3517. Another timeout happens before Recover is crossed, now > *without any additional state* there is no way to differentiate > this from case (b). > > There should be some additional state associated with the value > stored in Recover which is if FRTO declared a real timeout. Now you > can say only reset Recover = SndUna only if Recover is not > associated with a real timeout. If we want to avoid implementation > bugs we need to be prescriptive here so it may not be enough to say > " On the other hand, the draft says > that F-RTO SHOULD NOT be applied when an earlier SACK recovery is in > progress" Because it doesn't clarify how case (b) is different from > (c). In both cases an earlier SACK recovery is in progress. > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 14 21:00:03 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAAFB3A6B62; Fri, 14 Mar 2008 21:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 UHDfLxIrwgMD; Fri, 14 Mar 2008 21:00:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE183A6967; Fri, 14 Mar 2008 21:00:03 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 56C9F3A6967; Fri, 14 Mar 2008 21:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080315040001.56C9F3A6967@core3.amsl.com> Date: Fri, 14 Mar 2008 21:00:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-03.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-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 : ICMP attacks against TCP Author(s) : F. Gont Filename : draft-ietf-tcpm-icmp-attacks-03.txt Pages : 38 Date : 2008-03-14 This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. Additionally, describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-icmp-attacks-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-14204857.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 Sun Mar 16 21:01:10 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D7C3A6B1E; Sun, 16 Mar 2008 21:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.378 X-Spam-Level: X-Spam-Status: No, score=-101.378 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 nlHCJfnXKUjV; Sun, 16 Mar 2008 21:01:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876093A689D; Sun, 16 Mar 2008 21:01: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 D51673A6830 for ; Sun, 16 Mar 2008 21:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 mfY+vsUc8BYv for ; Sun, 16 Mar 2008 21:01:07 -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 2FB713A689D for ; Sun, 16 Mar 2008 21:01:07 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 Mar 2008 20:58:51 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2H3wob7012401; Sun, 16 Mar 2008 20:58:50 -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 m2H3wouR009707; Mon, 17 Mar 2008 03:58:50 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Mar 2008 20:58:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 16 Mar 2008 20:58:25 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804DDA0A6@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tcpsecure draft Thread-Index: AciH2VzwL6hKegJqRyiPAkz1XrhlGAAApleA References: From: "Anantha Ramaiah (ananth)" To: "Patrick Collison" X-OriginalArrivalTime: 17 Mar 2008 03:58:50.0567 (UTC) FILETIME=[358ABD70:01C887E3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3870; t=1205726330; x=1206590330; 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=20Tcpsecure=20draft |Sender:=20; bh=8fqAXQh4PtKUjz/ySkLE30e9jC0hW9RX8OenfjZcPWQ=; b=SYuOMJGWpLyaJb94FooiGYwL5HrrXd/6dXEvhiLwKeJdGXfWTo2aZgTE/A +hl9qS5qqVy79v2bS4m53BLjAXfEkpt54VJv+/XQiXlui63yLw3iIqGXler5 BtnXk9vHVQ; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: TCP Maintenance and Minor Extensions WG Subject: Re: [tcpm] Tcpsecure draft 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-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 Patrick, Pl see some comments inline to your queries.. > -----Original Message----- > From: Patrick Collison [mailto:patrick@collison.ie] > Sent: Sunday, March 16, 2008 7:48 PM > To: Anantha Ramaiah (ananth) > Subject: Tcpsecure draft > > Hi, > > I just read the latest tcpsecure draft > (http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure > -09.txt), > and have a question. I'm sure where the best place to ask is; > feel free to tell me to go elsewhere! The mailing list is tcpm@ietf.org. Some ietf lists have the requirement that you have to be subscribed to the list to send questions or else the emails would be on hold before until some verification is done. I am not sure about tcpm. > > In section 3.2 B, it's stated that a valid sequence number > attached to a RST packet MUST reset the connection without > further transmission. Yes this is just the default behaviour anyway since the valid seq# would RST the connection. (ie., without the draft being implemented) > > This has the problem that an attacker with very good > information (for example, where intermediate routers are > somehow colluding with the attacker -- as with Audible Magic > being deployed at ISPs, > http://w2.eff.org/share/audible_magic.php) can trivially > guess the correct sequence number range, and send a couple of > RSTs that are all-but guaranteed to trigger a reset. Yep, all bets are lost if the attacker can guess the correct sequence # unless other protection mechanisms (which the draft talks about) are in place. > > I raise this because I'm in the process of implementing RST > spoofing protection in xnu, and saw that the draft has a very > similar solution to what I'd ended up with (zero-length ACKs > on receipt of RST, plus throttling). To mitigate the above > case, where the attacker can easily guess the correct > sequence number, I plan to either 1) send an ACK for all RSTs > (within the bounds of the ACK throttling) or 2) send an ACK > for all RSTs once a single bad RST packet has been received > for a particular TCP. Couple of issues, I can see :- #1 The attacker can send 2 consecutive RST's (with some random delay between those) with exact sequence number, with your soluton you will respond with ACK for the first RST segment, and suppose you receive the second RST (again from the attacker), you will tear down the connection. #2 you are penalizing a well behaving host which sends the exact seq#, in other words, with your solution an RST would always incur a extra RTT to tear down the connection. > > Both solutions have their drawbacks, so this will probably be > solved by means of a tuneable parameter, with 2 likely being > the default. Sure, but see above corner case. > > Have the authors considered this situation? (And if so, was > it decided that the changes that mitigating this would require are too > extensive?) No, if the sequence # of the incoming RST = RCV.NXT, TCP would tear down the connection, that's what we have. One of the main objections by some people was that this solution "adds" an "arc' in the TCP state diagram and if we would have proposed sending an ACK for all RST's (including the ones matching the seq#) then it would have invited even more resistance. But you are free to propose this :-) > > Lastly, is there a public mailing list where the discussion > surrounding these drafts has taken place? Yes, the working version of this draft is -09- and that should give you a clue on the age of this draft :-) Your second question is already answered above. I am also taking the liberty to cc the mailing list to keep them in the loop. -Anantha > > Cheers, > > Patrick > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 19 17:31:43 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAB783A6872; Wed, 19 Mar 2008 17:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.248 X-Spam-Level: X-Spam-Status: No, score=-101.248 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 cOClIGGr9BPG; Wed, 19 Mar 2008 17:31:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC8F3A6883; Wed, 19 Mar 2008 17:31: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 3EDE03A6973 for ; Wed, 19 Mar 2008 17:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 EIchObRvjf48 for ; Wed, 19 Mar 2008 17:31:41 -0700 (PDT) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.76]) by core3.amsl.com (Postfix) with ESMTP id 293113A6872 for ; Wed, 19 Mar 2008 17:31:41 -0700 (PDT) Received: from mac.com (asmtp006-s [10.150.69.69]) by smtpoutm.mac.com (Xserve/smtpout013/MantshX 4.0) with ESMTP id m2K0TL8Y001472; Wed, 19 Mar 2008 17:29:21 -0700 (PDT) Received: from [192.168.1.85] (adsl-70-231-230-106.dsl.snfc21.sbcglobal.net [70.231.230.106]) (authenticated bits=0) by mac.com (Xserve/asmtp006/MantshX 4.0) with ESMTP id m2K0TGaq026871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Mar 2008 17:29:18 -0700 (PDT) Message-Id: From: Sally Floyd To: Lars Eggert In-Reply-To: <0A9BAFBD-68F2-4EC8-AC86-009905F9F01E@nokia.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 19 Mar 2008 17:29:16 -0700 References: <20080212040134.0C2093AEC52@lawyers.icir.org> <0A9BAFBD-68F2-4EC8-AC86-009905F9F01E@nokia.com> X-Mailer: Apple Mail (2.919.2) Cc: Aleksandar Kuzmanovic , tcpm , Ted Faber , mallman@icir.org, Amit Mondal , "K. K. Ramakrishnan" Subject: Re: [tcpm] AD review: draft-ietf-tcpm-ecnsyn-05 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-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 Lars - > I did my AD review for draft-ietf-tcpm-ecnsyn-05. Basically, it's > good to go to IETF last call. There are a few minor suggestions and > nits below. I'd suggest that we go to IETF Last Call and fix these > together with any other comments that we receive during the comment > period. > > (Alternatively, the authors could do another revisions now. Up to > you, just let me know which way you're going, so I can initiate the > last call or wait.) Many thanks for the feedback. I have made the changes (detailed feedback is below), and the revised draft is at: http://www.icir.org/floyd/papers/draft-ietf-tcpm-ecnsyn-06.txt http://www.icir.org/floyd/papers/draft-ietf-tcpm-ecnsyn-06.pdf I will submit it tomorrow. (And by Friday I will have the simulation scripts on-line.) Many thanks, Sally The detailed feedback: > INTRODUCTION, paragraph 13: > > This document is intended to update RFC 3168. > > s/is intended to update/updates/ > and also add an "Updates: 3168" header to the boilerplate. DONE. > Section 3., paragraph 0: > > 3. Proposal > > s/Proposal/Specification/ > (or Recommendation, but because the text below "only" changes a > MUST NOT to a MAY, that may be too strong) > > > Section 3., paragraph 3: > > Assume that TCP node A transmits to TCP node B an ECN-setup SYN > > packet, indicating willingness to use ECN for this connection. > As > > specified by RFC 3168, if TCP node B is willing to use ECN, > node B > > responds with an ECN-setup SYN-ACK packet. > > Suggestion: Start a new section before this paragraph, because the > remainder of the original section is more of a description of the > effects of the change, rather than continuing the specification. Actually, there is some SHOULDs and a MUST in the rest of that section. I made sub-sections, to make it more clear. > Section 4., paragraph 0: > > 4. Discussion > > Nit: Section would be more readable if "Motivation:", "Flooding > attacks:" etc. became real, numbered subsections. (Same in Section > 7.) DONE. > Section 6.2., paragraph 2: > > Simulations comparing the performance with Standard ECN (without > ECN- > > marked SYN/ACK packets), ECN+ with NoWaiting, and ECN+ with Waiting > > show little difference, in terms of aggregate congestion, between > > ECN+ with NoWaiting and ECN+ with Waiting. The details are given in > > Appendix A below. Our conclusions are that ECN+ with NoWaiting is > > perfectly safe, and there are no congestion-related reasons for > > preferring ECN+ with Waiting over ECN+ with NoWaiting. That is, > > there is no need for the TCP end-node to wait a round-trip time > > before sending a data packet after receiving an acknowledgement of > an > > ECN-marked SYN/ACK packet. > > That recommendation (that NoWaiting is safe and Waiting therefore > need > not be preferred) should also briefly be discussed in Section 4 where > the approaches are first described. DONE. > Or, if NoWaiting is preferred, > maybe the Waiting alternative should be moved out of Section 4 and > into another Section (this one?) I did the first one. > Section 8., paragraph 2: > > Future work will address the more general question of adding ECN- > > Capability to relevant handshake packets in other protocols that use > > retransmission-based reliability in their setup phase (e.g., SCTP, > > DCCP, HIP, and the like). > > That work doesn't seem to be happening, so I would suggest to remove > this section. DONE. > Section 100, paragraph 32: > > Capabililty for SYN/ACK packets, it is possible that the ECN-Capable > > Nit: s/Capabililty/Capability/ DONE. > Section 100, paragraph 46: > > [ECN-SYN] ECN-SYN web page with simulation scripts, URL to be added. > > URL needs to be added now. I added the URL (and I will add the simulations to the web page indicated by the URL by Friday...) > Section 100, paragraph 60: > > [SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also > > > > Might also want to refer to RFC 4987. DONE. Many thanks. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 25 15:32:07 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84E43A698F; Tue, 25 Mar 2008 15:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.125 X-Spam-Level: X-Spam-Status: No, score=-100.125 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 6DQAym9KM3sO; Tue, 25 Mar 2008 15:32:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D0C3A6AB2; Tue, 25 Mar 2008 15:32:07 -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 43D0C28C14A for ; Tue, 25 Mar 2008 15:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 EIv-uMKGKVd8 for ; Tue, 25 Mar 2008 15:32:02 -0700 (PDT) Received: from mx-out-01.forthnet.gr (unknown [193.92.150.105]) by core3.amsl.com (Postfix) with ESMTP id 1E88A28C10F for ; Tue, 25 Mar 2008 15:32:01 -0700 (PDT) Received: from mx-av-02.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id m2PMTehd028591; Wed, 26 Mar 2008 00:29:40 +0200 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id m2PMTeUI013224; Wed, 26 Mar 2008 00:29:40 +0200 Received: from hell.hell.gr (adsl7-208.lsf.forthnet.gr [79.103.134.208]) by MX-IN-02.forthnet.gr (8.14.2/8.14.2) with ESMTP id m2PMTc8l024929; Wed, 26 Mar 2008 00:29:40 +0200 Authentication-Results: MX-IN-02.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-02.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: tcpm@ietf.org Date: Wed, 26 Mar 2008 00:29:33 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803260029.33658.v13@v13.gr> Cc: bob.briscoe@bt.com Subject: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 Hello there, While experimenting I've written a (small) python program that utilizes the TCP weakness that is addressed in draft-moncaster-tcpm-rcv-cheat-02 (which I discovered latter). Using it, I was able to make an (under my control) HTTP server generate a constant 5-minute (until I interrupted it) 900Mbps traffic over the Internet using just a DSL line. Theoretically it could also be done using a 64Kbps ISDN line, it is 100% reproduceable and it can be used on many web servers with fast internet connections. I'm considering wether I should make this (small) tool public or not. On the plus side: It can be used as a proof of concept and for easily testing future implementations of this draft (if it becomes an RFC) On the minus side: Since it is very easy to use (no kernel patches etc), it can be easily abused by people that are not currently able to re-implement it. So, I kindly ask for your advice: Based on your experience, would it be of any use if I made this public? Thank you in advance, Harhalakis Stefanos _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 25 21:28:21 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B620F28C13E; Tue, 25 Mar 2008 21:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 LSFpsXclw5bL; Tue, 25 Mar 2008 21:28:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A96B13A687C; Tue, 25 Mar 2008 21:28:20 -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 D6CF63A687C for ; Tue, 25 Mar 2008 21:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 MEUhisBKjgAj for ; Tue, 25 Mar 2008 21:28:17 -0700 (PDT) Received: from circular.cs.umd.edu (circular.cs.umd.edu [128.8.128.176]) by core3.amsl.com (Postfix) with ESMTP id 712FC3A67F4 for ; Tue, 25 Mar 2008 21:28:17 -0700 (PDT) Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by circular.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id m2Q4Pr3l019243; Wed, 26 Mar 2008 00:25:53 -0400 Received: from loompa.cs.umd.edu (localhost [127.0.0.1]) by loompa.cs.umd.edu (8.13.8+Sun/8.12.5) with ESMTP id m2Q4PFM4012331; Wed, 26 Mar 2008 00:25:15 -0400 (EDT) Received: (from capveg@localhost) by loompa.cs.umd.edu (8.13.8+Sun/8.13.8/Submit) id m2Q4PFUQ012329; Wed, 26 Mar 2008 00:25:15 -0400 (EDT) Date: Wed, 26 Mar 2008 00:25:15 -0400 From: Rob Sherwood To: Stefanos Harhalakis Message-ID: <20080326042515.GD24842@cs.umd.edu> References: <200803260029.33658.v13@v13.gr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200803260029.33658.v13@v13.gr> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: tcpm@ietf.org, bob.briscoe@bt.com Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 On Wed, Mar 26, 2008 at 12:29:33AM +0200, Stefanos Harhalakis wrote: > Hello there, > > While experimenting I've written a (small) python program that utilizes the > TCP weakness that is addressed in draft-moncaster-tcpm-rcv-cheat-02 (which I > discovered latter). Using it, I was able to make an (under my control) HTTP > server generate a constant 5-minute (until I interrupted it) 900Mbps traffic > over the Internet using just a DSL line. Theoretically it could also be done > using a 64Kbps ISDN line, it is 100% reproduceable and it can be used on many > web servers with fast internet connections. > > I'm considering wether I should make this (small) tool public or not. As a data point, I have choosen not to publish the PoC code I created for this attack ("TCP Receivers Can Cause Internet-Wide Congestion Collapse" CCS 2005). While I am a strong proponent of full disclosure, I don't think releasing the code will speed the acceptance of the proposed solution. - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 26 07:42:05 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7985328C5BB; Wed, 26 Mar 2008 07:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.148 X-Spam-Level: X-Spam-Status: No, score=-100.148 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 2GYRU-MzCGoT; Wed, 26 Mar 2008 07:42:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A65428C275; Wed, 26 Mar 2008 07:42:00 -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 B7ACF28C5DB for ; Wed, 26 Mar 2008 07:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 89fC7l+7NO6F for ; Wed, 26 Mar 2008 07:41:51 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 7AFEA3A6882 for ; Wed, 26 Mar 2008 07:41:07 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 14:38:46 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 14:38:46 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1206542326769; Wed, 26 Mar 2008 14:38:46 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2QEchkI001007; Wed, 26 Mar 2008 14:38:45 GMT Message-Id: <200803261438.m2QEchkI001007@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Mar 2008 14:38:53 +0000 To: Stefanos Harhalakis From: Bob Briscoe In-Reply-To: <20080326042515.GD24842@cs.umd.edu> References: <200803260029.33658.v13@v13.gr> <20080326042515.GD24842@cs.umd.edu> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 26 Mar 2008 14:38:46.0645 (UTC) FILETIME=[191B0A50:01C88F4F] Cc: tcpm@ietf.org Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 Stefanos, I'd tend to agree with ROb - publication is unlikely to get the solution out there any quicker. If you're willing, you can always make the code available but require the downloader to contact you personally for a copy. Not ideal, but a decent compromise. BOb At 04:25 26/03/2008, Rob Sherwood wrote: >On Wed, Mar 26, 2008 at 12:29:33AM +0200, Stefanos Harhalakis wrote: > > Hello there, > > > > While experimenting I've written a (small) python program that > utilizes the > > TCP weakness that is addressed in > draft-moncaster-tcpm-rcv-cheat-02 (which I > > discovered latter). Using it, I was able to make an (under my > control) HTTP > > server generate a constant 5-minute (until I interrupted it) > 900Mbps traffic > > over the Internet using just a DSL line. Theoretically it could > also be done > > using a 64Kbps ISDN line, it is 100% reproduceable and it can be > used on many > > web servers with fast internet connections. > > > > I'm considering wether I should make this (small) tool public or not. > >As a data point, I have choosen not to publish the PoC code I created >for this attack ("TCP Receivers Can Cause Internet-Wide Congestion >Collapse" CCS 2005). While I am a strong proponent of full disclosure, >I don't think releasing the code will speed the acceptance of the >proposed solution. > >- Rob >. >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 26 11:24:25 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D4A28C6A6; Wed, 26 Mar 2008 11:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.473 X-Spam-Level: X-Spam-Status: No, score=-100.473 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 r1kwYYypaet2; Wed, 26 Mar 2008 11:24:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D593A6DB6; Wed, 26 Mar 2008 11:24:19 -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 0467C3A6DB6 for ; Wed, 26 Mar 2008 11:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 YByjwScXgbf2 for ; Wed, 26 Mar 2008 11:24:16 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 77A9C3A6B60 for ; Wed, 26 Mar 2008 11:24:16 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2QILpb4028114; Wed, 26 Mar 2008 20:21:51 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2QILoDD028111; Wed, 26 Mar 2008 20:21:50 +0200 Date: Wed, 26 Mar 2008 20:21:49 +0200 (EET) From: Pekka Savola To: Bob Briscoe In-Reply-To: <200803261438.m2QEchkI001007@bagheera.jungle.bt.co.uk> Message-ID: References: <200803260029.33658.v13@v13.gr> <20080326042515.GD24842@cs.umd.edu> <200803261438.m2QEchkI001007@bagheera.jungle.bt.co.uk> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.92.1/6391/Tue Mar 25 12:09:55 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: tcpm@ietf.org Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 On Wed, 26 Mar 2008, Bob Briscoe wrote: > I'd tend to agree with ROb - publication is unlikely to get the > solution out there any quicker. First, I suggest you or someone contact the most interesting vendors (some BSD and Linux communities) about this and potentially obtain a CVE number. Fernando Gont might be willing to help with this process as he has been through it before. However, on your main point I disagree; publication of PoC code is likely to trigger getting a CVE number, and that is likely to trigger some response especially in most security-aware (Linux, BSD) operating system vendors. There is ample evidence that vendors are willing to react even if the IETF progress is slow or nonexistent (e.g. ICMP errors draft); there is also ample evidence that vendors are not interested in putting (and should not be expected to put) the IETF on the critical path of shipping a product (or fixing a flaw). If the issue is not progressing in the IETF, I think it's exactly the right thing to do to release the PoC code; it would be nicer to contact vendors' security teams first and give them a heads-up e.g. 3 or 6 months in advance though. But if you believe this issue is progressing in the IETF, maybe publishing the PoC is premature. If the progress is slow I'd suggest contacting vendors' security teams now. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 26 12:36:46 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B940428C5D7; Wed, 26 Mar 2008 12:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.591 X-Spam-Level: X-Spam-Status: No, score=-100.591 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 DhLGfO-O9Q6A; Wed, 26 Mar 2008 12:36:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5FE28C18A; Wed, 26 Mar 2008 12:36: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 0B2623A6C0D for ; Wed, 26 Mar 2008 12:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 qCBqZiDT-C56 for ; Wed, 26 Mar 2008 12:36:40 -0700 (PDT) Received: from circular.cs.umd.edu (circular.cs.umd.edu [128.8.128.176]) by core3.amsl.com (Postfix) with ESMTP id 0720828C196 for ; Wed, 26 Mar 2008 12:36:39 -0700 (PDT) Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by circular.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id m2QJYCoq019550; Wed, 26 Mar 2008 15:34:12 -0400 Received: from loompa.cs.umd.edu (localhost [127.0.0.1]) by loompa.cs.umd.edu (8.13.8+Sun/8.12.5) with ESMTP id m2QJXsIg005062; Wed, 26 Mar 2008 15:33:54 -0400 (EDT) Received: (from capveg@localhost) by loompa.cs.umd.edu (8.13.8+Sun/8.13.8/Submit) id m2QJXcJf005057; Wed, 26 Mar 2008 15:33:38 -0400 (EDT) Date: Wed, 26 Mar 2008 15:33:38 -0400 From: Rob Sherwood To: Pekka Savola Message-ID: <20080326193338.GO24842@cs.umd.edu> References: <200803260029.33658.v13@v13.gr> <20080326042515.GD24842@cs.umd.edu> <200803261438.m2QEchkI001007@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: tcpm@ietf.org Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 On Wed, Mar 26, 2008 at 08:21:49PM +0200, Pekka Savola wrote: > On Wed, 26 Mar 2008, Bob Briscoe wrote: > > I'd tend to agree with ROb - publication is unlikely to get the > > solution out there any quicker. > > First, I suggest you or someone contact the most interesting vendors > (some BSD and Linux communities) about this and potentially obtain a > CVE number. Fernando Gont might be willing to help with this process > as he has been through it before. When I first published my paper (2005), I brought the issue up with CERT and they issued the problem [VU#102014] (http://www.kb.cert.org/vuls/id/102014). While not a CVE, I believe it has the same effect (maybe others may disagree). > But if you believe this issue is progressing in the IETF, maybe > publishing the PoC is premature. If the progress is slow I'd suggest > contacting vendors' security teams now. I contact vendors in 2005, and the response was luke warm (as was the response on this list). My take on this issue is that people are divided into three[1] camps: a) people who do not believe this attack practical b) people who believe the attack is practical, but not dangerous enough to motivate patching TCP implementations c) people who believe this attack is practical and dangerous, but felt my randomly-skipped segments solution was not "good" for reasons of efficiency, correctness, etc. In my mind, publishing the PoC could convince people in group (a) to move to group (b). If the attack were to become active in the wild, then maybe people might move from (b) to (c). But that still leaves the bottleneck on people in group (c) to come up with a "good" solution. Bob Briscoe et al. have come up with a variant on my solution, but I am not certain how well its been scrutinised or if it has even been implemented. So, in my mind, the best case is that publishing the PoC could get more people looking at potential solutions to the attack, at the cost of potentially causing widespread DoS. Given that analysis, I chose not to publish my code, but I will leave it to Stefanos to decide what to do with his. - Rob . [1] I guess there is a forth group (namely, me) that believed the attack was practical and dangerous, and that the skipped segment solution was good, but I guess we can discount that :-) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 26 12:46:32 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47FD28C79B; Wed, 26 Mar 2008 12:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 S8GplpSjL3p6; Wed, 26 Mar 2008 12:46:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9961128C741; Wed, 26 Mar 2008 12:46:31 -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 6BDB028C741 for ; Wed, 26 Mar 2008 12:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 rxiH314l1HmD for ; Wed, 26 Mar 2008 12:46:28 -0700 (PDT) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id A487728C798 for ; Wed, 26 Mar 2008 12:46:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 15:41:12 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703442C8F@nekter> In-Reply-To: <20080326193338.GO24842@cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 Thread-Index: AciPeHeZCoeZEn+kS+GO1mq7bxBifQAAFVNA References: <200803260029.33658.v13@v13.gr> <20080326042515.GD24842@cs.umd.edu><200803261438.m2QEchkI001007@bagheera.jungle.bt.co.uk> <20080326193338.GO24842@cs.umd.edu> From: "Caitlin Bestler" To: "Rob Sherwood" , "Pekka Savola" Cc: tcpm@ietf.org Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 > Rob Sherwood wrote > > I contact vendors in 2005, and the response was luke warm (as was the > response on this list). My take on this issue is that people are > divided into three[1] camps: > > a) people who do not believe this attack practical > b) people who believe the attack is practical, but not dangerous enough > to motivate patching TCP implementations I'd rephrase that as: b) people who believe the attack is practical, but that the problem is an application layer problem that should be solved at the application layer -- and especially not by transport layer solutions that would have a negative impact on honest connections. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 26 13:03:02 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFCD428C6A3; Wed, 26 Mar 2008 13:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.982 X-Spam-Level: X-Spam-Status: No, score=-100.982 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 DlgMg-DPha0Z; Wed, 26 Mar 2008 13:03:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D482B3A6E0F; Wed, 26 Mar 2008 13:03:00 -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 16CFE3A6DE0 for ; Wed, 26 Mar 2008 13:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 I+ieVdC4HNRF for ; Wed, 26 Mar 2008 13:02:53 -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 32E173A6E0F for ; Wed, 26 Mar 2008 13:02:53 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Mar 2008 13:00:34 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2QK0X4b000360; Wed, 26 Mar 2008 13:00:33 -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 m2QK0X3f026873; Wed, 26 Mar 2008 20:00:33 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 13:00:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 13:00:05 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804E8BAEE@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7703442C8F@nekter> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 Thread-Index: AciPeHeZCoeZEn+kS+GO1mq7bxBifQAAFVNAAABRfBA= References: <200803260029.33658.v13@v13.gr><20080326042515.GD24842@cs.umd.edu><200803261438.m2QEchkI001007@bagheera.jungle.bt.co.uk><20080326193338.GO24842@cs.umd.edu> <78C9135A3D2ECE4B8162EBDCE82CAD7703442C8F@nekter> From: "Anantha Ramaiah (ananth)" To: "Caitlin Bestler" , "Rob Sherwood" , "Pekka Savola" X-OriginalArrivalTime: 26 Mar 2008 20:00:33.0103 (UTC) FILETIME=[0CA6BDF0:01C88F7C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2009; t=1206561633; x=1207425633; 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]=20PoC=20for=20draft-moncaster-tc pm-rcv-cheat-02 |Sender:=20; bh=JsKuE2ciAoO3jGEUiaLAposIQoZss+zX5vWMWiFV794=; b=E0xS0gY03JgPy7RisB8ZPbfvM8RUtoogJ+eFDwULcSvG7i8JYPonl1yD7d Dua7SE+YeJaXVNMTpyOsB7KfzDRC1Mr7JNVII2gm+mDC4MwoPw5HskhytpzK /ao2/DUJGk; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 Ok the following a general comment/observation and just my opinion. There are a class of problems that CAN be solved in application layers, but those solution doesn't scale ( all applications need to be fixed), in such cases if we make minor tweaks in the transport layer with larger benefits ( meaning a multitude of transport apps), and if the benefits of doing so outweigh the drawbacks, then we should hoenstly pursue or make an attempt to pursue it. In other words a rejection of a transport proposal cannot be simply based on the fact that "you can possibly solve this in application layer", wait a minute, I am also not advocating that all applications problems need to be solved in transport layers. Well, David Clark's quote on layering comes to mind as well. S0.02, -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Caitlin Bestler > Sent: Wednesday, March 26, 2008 12:41 PM > To: Rob Sherwood; Pekka Savola > Cc: tcpm@ietf.org > Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 > > > Rob Sherwood wrote > > > > I contact vendors in 2005, and the response was luke warm > (as was the > > response on this list). My take on this issue is that people are > > divided into three[1] camps: > > > > a) people who do not believe this attack practical > > b) people who believe the attack is practical, but not dangerous > enough > > to motivate patching TCP implementations > > I'd rephrase that as: > > b) people who believe the attack is practical, but that the > problem is an > application layer problem that should be solved at the > application layer > -- and especially not by transport layer solutions that would have a > negative impact on honest connections. > > > > _______________________________________________ > 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 Mar 26 13:07:53 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487B828C6B6; Wed, 26 Mar 2008 13:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.591 X-Spam-Level: X-Spam-Status: No, score=-100.591 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 MO0jSEs4vLVm; Wed, 26 Mar 2008 13:07:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 561B328C2F2; Wed, 26 Mar 2008 13:07: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 3BBD53A6E23 for ; Wed, 26 Mar 2008 13:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 4CnEElYDAK9z for ; Wed, 26 Mar 2008 13:07:46 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 5A5723A6DE0 for ; Wed, 26 Mar 2008 13:07:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 29FE0C01BF4; Wed, 26 Mar 2008 13:05:27 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14411-05; Wed, 26 Mar 2008 13:05:27 -0700 (PDT) Received: from [127.0.0.1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id DA8C1C01BF7; Wed, 26 Mar 2008 13:05:26 -0700 (PDT) Message-ID: <47EAAC87.2090606@redback.com> Date: Wed, 26 Mar 2008 13:05:27 -0700 From: Jakob Heitz User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tcpm@ietf.org References: <200803260029.33658.v13@v13.gr> <20080326042515.GD24842@cs.umd.edu><200803261438.m2QEchkI001007@bagheera.jungle.bt.co.uk> <20080326193338.GO24842@cs.umd.edu> <78C9135A3D2ECE4B8162EBDCE82CAD7703442C8F@nekter> In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7703442C8F@nekter> X-Virus-Scanned: by amavisd-new at redback.com Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 Intentionally dropping segments at the sender has an unacceptable negative impact on honest connections. No wonder this never flew. You can detect a possible attacker of this nature just by looking for acks of segments you have not yet sent. After all, the attacker is sending acks for what he didn't receive, so he has no idea how far into the future to ack. Even if you look for future acks, they may be legit ones from a previous connection or old ones from the same connection if the sequence space has wrapped. So I suggest as a defense, if you receive an ack of the future, to halve the congestion window. Caitlin Bestler wrote: >> Rob Sherwood wrote >> >> I contact vendors in 2005, and the response was luke warm (as was the >> response on this list). My take on this issue is that people are >> divided into three[1] camps: >> >> a) people who do not believe this attack practical >> b) people who believe the attack is practical, but not dangerous > enough >> to motivate patching TCP implementations > > I'd rephrase that as: > > b) people who believe the attack is practical, but that the problem is > an > application layer problem that should be solved at the application > layer > -- and especially not by transport layer solutions that would have a > negative impact on honest connections. > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Jakob Heitz. x5475. 510-566-2901 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 26 13:21:49 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B661C28C778; Wed, 26 Mar 2008 13:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 VN5qMTduGamE; Wed, 26 Mar 2008 13:21:36 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8672A28C315; Wed, 26 Mar 2008 13:21: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 3AB9928C375 for ; Wed, 26 Mar 2008 13:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 BCimnW4QpJMD for ; Wed, 26 Mar 2008 13:21:33 -0700 (PDT) Received: from circular.cs.umd.edu (circular.cs.umd.edu [128.8.128.176]) by core3.amsl.com (Postfix) with ESMTP id AE49B28C780 for ; Wed, 26 Mar 2008 13:20:49 -0700 (PDT) Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by circular.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id m2QKITLR005525; Wed, 26 Mar 2008 16:18:29 -0400 Received: from loompa.cs.umd.edu (localhost [127.0.0.1]) by loompa.cs.umd.edu (8.13.8+Sun/8.12.5) with ESMTP id m2QKIQIb007420; Wed, 26 Mar 2008 16:18:26 -0400 (EDT) Received: (from capveg@localhost) by loompa.cs.umd.edu (8.13.8+Sun/8.13.8/Submit) id m2QKIQUI007419; Wed, 26 Mar 2008 16:18:26 -0400 (EDT) Date: Wed, 26 Mar 2008 16:18:26 -0400 From: Rob Sherwood To: Caitlin Bestler Message-ID: <20080326201826.GP24842@cs.umd.edu> References: <200803260029.33658.v13@v13.gr> <20080326193338.GO24842@cs.umd.edu> <78C9135A3D2ECE4B8162EBDCE82CAD7703442C8F@nekter> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7703442C8F@nekter> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: tcpm@ietf.org Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 On Wed, Mar 26, 2008 at 03:41:12PM -0400, Caitlin Bestler wrote: > I'd rephrase that as: > > b) people who believe the attack is practical, but that the problem is > an > application layer problem that should be solved at the application > layer > -- and especially not by transport layer solutions that would have a > negative impact on honest connections. I would call this a different camp all together, mostly because it's one I least understand the rationale for. Maybe you could reiterate your points for me (off list, if you think this issue is dead)? I feel like this view comes from a misunderstanding of the attack. In my view, the goal of the attack is not to saturate the first hop of a single victim. Instead, the attacker's goal is to fool many victims in parallel into saturating their shared access and backbone links by the *aggregate traffic*. Thus, no one victim is sending abnormally fast, but the aggregate level of traffic ( summed across victims) is sufficient to cause DoS. To paraphrase, this is an attack against the network not an individual. So, when one views the attack from this standpoint, I don't see how application level rate limits (which, IIRC, is what you were proposing) would stop this attack: no one victim is sending at an excessive rate. - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 26 13:23:22 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B183028C790; Wed, 26 Mar 2008 13:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.707 X-Spam-Level: X-Spam-Status: No, score=-100.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 J1A9eFEq31wu; Wed, 26 Mar 2008 13:23:13 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F6A28C3B2; Wed, 26 Mar 2008 13:23:13 -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 DBF7F28C375 for ; Wed, 26 Mar 2008 13:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 X2kma5qw6RPH for ; Wed, 26 Mar 2008 13:23:09 -0700 (PDT) Received: from kac.cnri.dit.ie (unknown [IPv6:2001:770:68:ff::1]) by core3.amsl.com (Postfix) with ESMTP id 2352C3A6F78 for ; Wed, 26 Mar 2008 13:23:08 -0700 (PDT) Received: from kac.cnri.dit.ie (localhost.cnri.dit.ie [127.0.0.1]) by kac.cnri.dit.ie (8.13.4/8.13.4) with ESMTP id m2QKKjQ8001227; Wed, 26 Mar 2008 20:20:45 GMT (envelope-from dwmalone@kac.cnri.dit.ie) Message-Id: <200803262020.m2QKKjQ8001227@kac.cnri.dit.ie> To: Jakob Heitz In-Reply-To: Your message of "Wed, 26 Mar 2008 13:05:27 MST." <47EAAC87.2090606@redback.com> From: David Malone Date: Wed, 26 Mar 2008 20:20:45 +0000 Cc: tcpm@ietf.org Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 > So I suggest as a defense, if you receive an ack of > the future, to halve the congestion window. In the demo at: http://www.hamilton.ie/gavinmc/drop_dupack_attack/ Gavin only acked packets that were sent - there is no need to ack into the future. David. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 26 13:27:42 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C0A928C340; Wed, 26 Mar 2008 13:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.603 X-Spam-Level: X-Spam-Status: No, score=-100.603 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 y5Gki2knt1dG; Wed, 26 Mar 2008 13:27:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E353A695F; Wed, 26 Mar 2008 13:27: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 717A128C2ED for ; Wed, 26 Mar 2008 13:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 8m6QY0aN+QG3 for ; Wed, 26 Mar 2008 13:27:39 -0700 (PDT) Received: from circular.cs.umd.edu (circular.cs.umd.edu [128.8.128.176]) by core3.amsl.com (Postfix) with ESMTP id 434E33A6DBF for ; Wed, 26 Mar 2008 13:27:39 -0700 (PDT) Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by circular.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id m2QKPDgB025022; Wed, 26 Mar 2008 16:25:13 -0400 Received: from loompa.cs.umd.edu (localhost [127.0.0.1]) by loompa.cs.umd.edu (8.13.8+Sun/8.12.5) with ESMTP id m2QKP1Ib007741; Wed, 26 Mar 2008 16:25:01 -0400 (EDT) Received: (from capveg@localhost) by loompa.cs.umd.edu (8.13.8+Sun/8.13.8/Submit) id m2QKP1s2007740; Wed, 26 Mar 2008 16:25:01 -0400 (EDT) Date: Wed, 26 Mar 2008 16:25:01 -0400 From: Rob Sherwood To: Jakob Heitz Message-ID: <20080326202501.GQ24842@cs.umd.edu> References: <200803260029.33658.v13@v13.gr> <20080326193338.GO24842@cs.umd.edu> <78C9135A3D2ECE4B8162EBDCE82CAD7703442C8F@nekter> <47EAAC87.2090606@redback.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <47EAAC87.2090606@redback.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: tcpm@ietf.org Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 On Wed, Mar 26, 2008 at 01:05:27PM -0700, Jakob Heitz wrote: > Intentionally dropping segments at the sender > has an unacceptable negative impact on honest > connections. No wonder this never flew. My experiments have show this to be a <0.01% impact on perfomance and no impact on correctness. You might argue that my experiments do not have a wide deployment and might depend on network conditions, but I don't know why you say the solution is "unacceptable". > You can detect a possible attacker of this nature > just by looking for acks of segments you have > not yet sent. After all, the attacker is sending > acks for what he didn't receive, so he has no idea > how far into the future to ack. > Even if you look for future acks, they may be legit > ones from a previous connection or old ones from > the same connection if the sequence space has wrapped. > > So I suggest as a defense, if you receive an ack of > the future, to halve the congestion window. As I say in my paper, this is not a reasonable defense. 1) The attack does not necessarily send Acks ahead of what is sent and I outline a number of ways to avoid doing so. 2) If this is the detection condition, it opens a new DoS where a different type of attacker can inject out-of-window Acks into valid connections to create false possitives in this test. Thus, if what you propose were implemented, a third party could force the congestion window to be arbitarily small for a connection between two honest nodes, without guessing the sequence number. - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 26 17:42:41 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5581F28C7FA; Wed, 26 Mar 2008 17:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.494 X-Spam-Level: X-Spam-Status: No, score=-100.494 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 euV63pWVQVem; Wed, 26 Mar 2008 17:42:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71FE43A6BF8; Wed, 26 Mar 2008 17:42:40 -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 158EF3A6BF8 for ; Wed, 26 Mar 2008 17:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 5Hjp8Gk6DcCC for ; Wed, 26 Mar 2008 17:42:34 -0700 (PDT) Received: from mx-out-03.forthnet.gr (mx-out.forthnet.gr [193.92.150.105]) by core3.amsl.com (Postfix) with ESMTP id F0EBC3A6AB7 for ; Wed, 26 Mar 2008 17:42:33 -0700 (PDT) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.13.8/8.13.8) with ESMTP id m2R0eOaY025919; Thu, 27 Mar 2008 02:40:24 +0200 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id m2R0e562027500; Thu, 27 Mar 2008 02:40:05 +0200 Received: from hell.hell.gr (adsl7-208.lsf.forthnet.gr [79.103.134.208]) by MX-IN-01.forthnet.gr (8.14.2/8.14.2) with ESMTP id m2R0dxXR015910; Thu, 27 Mar 2008 02:40:01 +0200 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-01.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: tcpm@ietf.org Date: Thu, 27 Mar 2008 02:39:50 +0200 User-Agent: KMail/1.9.7 References: <200803260029.33658.v13@v13.gr> <20080326193338.GO24842@cs.umd.edu> <78C9135A3D2ECE4B8162EBDCE82CAD7703442C8F@nekter> In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7703442C8F@nekter> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803270239.51008.v13@v13.gr> Cc: Caitlin Bestler Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 Hello Caitlin, On Wednesday 26 March 2008, Caitlin Bestler wrote: > I'd rephrase that as: > > b) people who believe the attack is practical, but that the problem is > an > application layer problem that should be solved at the application > layer > -- and especially not by transport layer solutions that would have a > negative impact on honest connections. I believe that people that find the above logical do not actually understand the issue. Let me explain: First, it is impossible for the application layer to distinguish legitimate clients from this kind of misbehaving receivers. Second, this has to do with exploiting TCP and not a group of applications. Third, this affects the network and the end-points and not the applications. This means that it has to be solved either in the intermediate network (routers) or at the end-point operating systems. Forth, it is a security issue that (at least) should be mentioned in congestion control related RFCs in the security considerations section. Since this only affects TCP and the network layer has (almost) nothing to do with congestion control, this becomes 100% a transport layer TCP issue. Perhaps we should just document this in an informational RFC and cooperate with or wait for vendors to solve it. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 27 10:14:49 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859783A6FF9; Thu, 27 Mar 2008 10:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.48 X-Spam-Level: X-Spam-Status: No, score=-98.48 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, USER_IN_WHITELIST=-100] 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 cc-lR0ydXrdJ; Thu, 27 Mar 2008 10:14:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 700EA3A6B76; Thu, 27 Mar 2008 10:14:48 -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 9F17F3A6FF9 for ; Thu, 27 Mar 2008 10:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 9dmjhV42Nq8N for ; Thu, 27 Mar 2008 10:14:42 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id CAC953A6C5E for ; Thu, 27 Mar 2008 10:14:39 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 51A0A5A8BAF; Thu, 27 Mar 2008 14:08:23 -0300 (ART) Received: from notebook.gont.com.ar (201-254-41-108.speedy.com.ar [201.254.41.108] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m2RH88ic024800; Thu, 27 Mar 2008 14:08:09 -0300 Message-Id: <200803271708.m2RH88ic024800@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Feb 2008 13:58:23 -0300 To: Stefanos Harhalakis , tcpm@ietf.org From: Fernando Gont In-Reply-To: <200803260029.33658.v13@v13.gr> References: <200803260029.33658.v13@v13.gr> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 27 Mar 2008 14:08:17 -0300 (ART) Cc: bob.briscoe@bt.com Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 At 07:29 p.m. 25/03/2008, Stefanos Harhalakis wrote: >I'm considering wether I should make this (small) tool public or not. > >On the plus side: It can be used as a proof of concept and for easily testing >future implementations of this draft (if it becomes an RFC) > >On the minus side: Since it is very easy to use (no kernel patches etc), it >can be easily abused by people that are not currently able to re-implement >it. > >So, I kindly ask for your advice: >Based on your experience, would it be of any use if I made this public? This issue was disclosed by US-CERT. That is, vendors were contacted, and had the chance to do something about it. It has a CVE name: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3675 , and there's a US-CERT report about it: http://www.kb.cert.org/vuls/id/102014 According to US-CERT's report, there has not been much of a response from vendors. I suggest you contact CERT and let them know that your planning to disclose your PoC. Set your own deadline as to until when you'd be willing to get a response on a way forward (i.e., are vendors going to be as unresponsive as they have been so far?) Additionally, contact developers at FreeBSD, NetBSD, OpenBSD and Linux. I can provide a few names at each, if you want. But they usually have some form of security@ contact. I know quite a few people at these projects that do care about security issues, and would be willing to implement counter-measures if they make sense. If the process with CERT doesn't go as expected, (and provided you have already talked with the open source projects and given them some time to do something about it), post your code to bugtraq and CC full-disclosure. Also include a pointer to Savage's paper and to Sherwood's paper, too. And also include a pointer to Moncaster's draft. I could also put you in contact with the right people at UK CPNI (http://www.cpni.gov.uk). In my own experience, they have proved to be more responsive, and much nicer to work with. Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 27 14:31:34 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B1B3A6E63; Thu, 27 Mar 2008 14:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.547 X-Spam-Level: X-Spam-Status: No, score=-100.547 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 X3NoYUbGlMtW; Thu, 27 Mar 2008 14:31:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEDFD28C2DC; Thu, 27 Mar 2008 14:31:30 -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 C5FA33A69B9 for ; Thu, 27 Mar 2008 14:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 tNJq70Zt2EzL for ; Thu, 27 Mar 2008 14:31:29 -0700 (PDT) Received: from mx-out-05.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id 3C31A3A6E42 for ; Thu, 27 Mar 2008 14:31:28 -0700 (PDT) Received: from mx-av-02.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.13.8/8.13.8) with ESMTP id m2RLT6Gv006720; Thu, 27 Mar 2008 23:29:06 +0200 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id m2RLT6Ea016415; Thu, 27 Mar 2008 23:29:06 +0200 Received: from hell.hell.gr (adsl7-208.lsf.forthnet.gr [79.103.134.208]) by MX-IN-02.forthnet.gr (8.14.2/8.14.2) with ESMTP id m2RLT3Ju011044; Thu, 27 Mar 2008 23:29:05 +0200 Authentication-Results: MX-IN-02.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-02.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: Fernando Gont Date: Thu, 27 Mar 2008 23:28:54 +0200 User-Agent: KMail/1.9.7 References: <200803260029.33658.v13@v13.gr> <200803271708.m2RH88ic024800@venus.xmundo.net> In-Reply-To: <200803271708.m2RH88ic024800@venus.xmundo.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803272328.54956.v13@v13.gr> Cc: tcpm@ietf.org, bob.briscoe@bt.com Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 On Wednesday 27 February 2008, Fernando Gont wrote: > This issue was disclosed by US-CERT. That is, vendors were contacted, > and had the chance to do something about it. Thank you for the information. It was very helpfull. After thinking it a lot, I decided to first disclose it in the form of a paper which should further alert vendors and security organizations (I'll contact them when it is ready) but it won't be used by script-kiddies reading the bugtraq. I believe that this is the best approach (tm) right now and that it won't do any harm. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 27 15:14:12 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38EE28C95A; Thu, 27 Mar 2008 15:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.797 X-Spam-Level: X-Spam-Status: No, score=-100.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 7wvdx62rgETD; Thu, 27 Mar 2008 15:14:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1D3828C932; Thu, 27 Mar 2008 15:14:11 -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 6D8D028C705 for ; Thu, 27 Mar 2008 15:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 MPUZgScJUu8F for ; Thu, 27 Mar 2008 15:14:10 -0700 (PDT) Received: from smtp1.is.depaul.edu (smtp1.is.depaul.edu [140.192.20.72]) by core3.amsl.com (Postfix) with ESMTP id 90E4028C7D2 for ; Thu, 27 Mar 2008 15:14:10 -0700 (PDT) Received: from condor.depaul.edu (condor.depaul.edu [140.192.1.6]) by smtp1.is.depaul.edu (Postfix) with ESMTP id 7C1003B4F1 for ; Thu, 27 Mar 2008 17:11:50 -0500 (CDT) Received: from jtk.local (localhost [127.0.0.1]) by condor.depaul.edu (Postfix) with SMTP id 1AC133B8 for ; Thu, 27 Mar 2008 17:11:48 -0500 (CDT) Date: Thu, 27 Mar 2008 17:11:47 -0500 From: John Kristoff To: tcpm@ietf.org In-Reply-To: <200803272328.54956.v13@v13.gr> References: <200803260029.33658.v13@v13.gr> <200803271708.m2RH88ic024800@venus.xmundo.net> <200803272328.54956.v13@v13.gr> X-Mailer: Sylpheed version 2.2.2 (GTK+ 2.8.12; i386-apple-darwin8.5.2) Mime-Version: 1.0 Message-Id: <20080327221148.1AC133B8@condor.depaul.edu> Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 On Thu, 27 Mar 2008 23:28:54 +0200 Stefanos Harhalakis wrote: > Thank you for the information. It was very helpfull. After thinking it a lot, > I decided to first disclose it in the form of a paper which should further > alert vendors and security organizations (I'll contact them when it is ready) > but it won't be used by script-kiddies reading the bugtraq. I believe that > this is the best approach (tm) right now and that it won't do any harm. From an operational perspective my personal opinion is that this is probably the best approach at this time. Releasing code is likely going to result in two things, pain for some and public notoriety for you. Sounds like your ego is already well intact. Thats good. :-) Perhaps you or a designated colleague would be willing to give a lightning talk and expose the attack(s) to a forum such as USENIX, RIPE or NANOG to help raise awareness? A few well formed graphs showing real-world results might get some influential operators and implementors to put mitigation higher on the priority list? John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 27 16:20:06 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042353A6ADE; Thu, 27 Mar 2008 16:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.379 X-Spam-Level: X-Spam-Status: No, score=-98.379 tagged_above=-999 required=5 tests=[AWL=-0.540, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 OLIn7bk8gkVt; Thu, 27 Mar 2008 16:20:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3DED3A6A77; Thu, 27 Mar 2008 16:20:04 -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 F3E333A6823 for ; Thu, 27 Mar 2008 16:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 2AhfSZ+o-2BZ for ; Thu, 27 Mar 2008 16:20:03 -0700 (PDT) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id EAB6C3A68A3 for ; Thu, 27 Mar 2008 16:20:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Mar 2008 19:14:44 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77034431B9@nekter> In-Reply-To: <20080326202501.GQ24842@cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 Thread-Index: AciPf5gS+2RvtEj9Q+2GCdJyj8RHWwA3aO6A References: <200803260029.33658.v13@v13.gr> <20080326193338.GO24842@cs.umd.edu><78C9135A3D2ECE4B8162EBDCE82CAD7703442C8F@nekter><47EAAC87.2090606@redback.com> <20080326202501.GQ24842@cs.umd.edu> From: "Caitlin Bestler" To: "Rob Sherwood" , "Jakob Heitz" Cc: tcpm@ietf.org Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 > Rob Sherwood > Sent: Wednesday, March 26, 2008 1:25 PM > To: Jakob Heitz > Cc: tcpm@ietf.org > Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 > > On Wed, Mar 26, 2008 at 01:05:27PM -0700, Jakob Heitz wrote: > > Intentionally dropping segments at the sender > > has an unacceptable negative impact on honest > > connections. No wonder this never flew. > > My experiments have show this to be a <0.01% impact on perfomance and > no impact on correctness. You might argue that my experiments do not > have a wide deployment and might depend on network conditions, but I > don't know why you say the solution is "unacceptable". > As a *test* described in an informational RFC there is no real problem with it. As a routine counter-measure it would have severe problems. On very high speed links the NIC and/or driver has very little choice but to implement one or more strategies to reduce the number of interactions with the TCP consumer. Delivering each TCP segment as soon as it is deliverable is not a viable option. These techniques could include interrupt coalescing, Large Receive Offload, TCP offload and others. Large Receive Offload in particular will be negatively impacted whenever the TCP sender does not faithfully send entire messages in order and as promptly as the TCP congestion control algorithms expect. LRO seeks to reduce the number of distinct notifications required to deliver a sequence of TCP Segments for the same connection, but in a manner that minimizes latency delays. When a gap indicates a lost packet the answer is simple, aggregate what you have and deliver it. When a gap really means that the sender is testing you then you still aggregate what you have and deliver it. And then deliver the deliberately mis-ordered segment separately. So the issue is not just the memory resources, but the number of distinct inter-layer notifications required, the number of times that a context switch between TCBs is required and the number of times a user context is switched. These all have a negative impact on not only memory usage, but memory bandwidth and cache efficiency. Indeed, if a sender engaged in deliberate TCP segment misordering on a regular basis it could be considered a Denial-of-service attack. This is something that can very easily be solved at the application layer, by simply requiring the application layer to periodically echo an application layer cookie back to the sender. A trivial AJAX script could handle this without a single change to the TCP layer. Using timestamps would also probably work. And if the client was unwilling to provide these echoes, just limit the bandwidth that you will provide to them. As for the "network" implications, this attack is a very poor candidate for a successful DoS attack because it requires the attacker to saturate a link that actually leads to them. The pattern of the attack would be easily detected, and once detected the destination IP address is easily traceable. Work in the IEEE's Data Center Bridging task group should lead to reduction or elimination of congestion drops within IP subnets. That means that TCP handling optimizations in NICs, drivers or TCP stacks that expect in-order delivery will be even more effective. The NICs and Bridges supporting these techniques will be going through a lot of extra work to provide largely lossless and in-order delivery of TCP segments. Deliberately sending them in the wrong order borders on being ungrateful. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 27 18:25:14 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA653A6874; Thu, 27 Mar 2008 18:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.978 X-Spam-Level: X-Spam-Status: No, score=-99.978 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 7Qu6TI5KXJUB; Thu, 27 Mar 2008 18:25:13 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28233A6951; Thu, 27 Mar 2008 18:25:13 -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 C924D3A680C for ; Thu, 27 Mar 2008 18:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 xVEB4qvvuhfI for ; Thu, 27 Mar 2008 18:25:06 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id B27B53A6951 for ; Thu, 27 Mar 2008 18:25:05 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 01:25:04 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 01:25:03 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1206667502770; Fri, 28 Mar 2008 01:25:02 +0000 Received: from mut.jungle.bt.co.uk ([10.73.208.182]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2S1OxJI028738; Fri, 28 Mar 2008 01:25:01 GMT Message-Id: <200803280125.m2S1OxJI028738@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 28 Mar 2008 01:25:10 +0000 To: Rob Sherwood From: Bob Briscoe In-Reply-To: <20080326193338.GO24842@cs.umd.edu> References: <200803260029.33658.v13@v13.gr> <20080326042515.GD24842@cs.umd.edu> <200803261438.m2QEchkI001007@bagheera.jungle.bt.co.uk> <20080326193338.GO24842@cs.umd.edu> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 28 Mar 2008 01:25:03.0677 (UTC) FILETIME=[8C6E4ED0:01C89072] Cc: tcpm@ietf.org Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 Rob, Just to be clear, our original aim was merely to put what you had done into IETF standards-speak because we believed you (and previous researchers on the same tack) had identified a serious vulnerability and a reasonable solution. However, on writing up the I-D, we quickly realised the TCPM w-g would likely have issues with some of the precise details of your approach, so we ended up inventing a slightly different but broadly similar approach. It's been fairly closely scrutinised technically on the list. I think we have satisfied most people that a 'good' solution is possible that has no harmful side-effects - at least in theory. You're right that we haven't simulated or implemented the deltas from your approach. This was originally a sideline activity - just a write up that turned into more than we had planned. Nonetheless, Toby Moncaster (the primary author) now has plans to simulate it and write up the outcome. I can't be more precise 'cos I'm responding on his behalf, as he's on his sick-bed at the mo. I guess if it became a WG item, he'd get simulations done sharpish. Bob At 19:33 26/03/2008, Rob Sherwood wrote: >My take on this issue is that people are >divided into three[1] camps: >---snip--- >c) people who believe this attack is practical and dangerous, but felt > my randomly-skipped segments solution was not "good" for > reasons of efficiency, correctness, etc. >---snip--- >But that still leaves >the bottleneck on people in group (c) to come up with a "good" >solution. Bob Briscoe et al. have come up with a variant on my >solution, but I am not certain how well its been scrutinised or if it >has even been implemented. ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 28 06:26:56 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49623A6B45; Fri, 28 Mar 2008 06:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.328 X-Spam-Level: X-Spam-Status: No, score=-101.328 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 1orc84gBtvhb; Fri, 28 Mar 2008 06:26:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A723A6C67; Fri, 28 Mar 2008 06:26: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 B0E823A6C67 for ; Fri, 28 Mar 2008 06:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 m1STa-g8tNdH for ; Fri, 28 Mar 2008 06:26:54 -0700 (PDT) Received: from ndjsbar01.ndc.nasa.gov (ndjsbar01.ndc.nasa.gov [198.120.25.38]) by core3.amsl.com (Postfix) with ESMTP id DC5DA3A69E2 for ; Fri, 28 Mar 2008 06:26:53 -0700 (PDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar01.ndc.nasa.gov (Spam Firewall) with ESMTP id 742E87DCCA2; Fri, 28 Mar 2008 08:26:52 -0500 (CDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar01.ndc.nasa.gov with ESMTP id 3bX6nWfZ3YAhHGRD; Fri, 28 Mar 2008 08:26:52 -0500 (CDT) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 08:26:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 08:26:51 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICCRG experimental CC reviews Thread-Index: AciQ12GuWgWF+gUnSd2SO6o5DTo0CQ== From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 28 Mar 2008 13:26:52.0073 (UTC) FILETIME=[623F1990:01C890D7] Cc: iccrg@cs.ucl.ac.uk Subject: [tcpm] ICCRG experimental CC reviews 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-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 The ICCRG has been attempting to prepare a "safety review" of Compound TCP as input to TCPM in deciding how to handle the Compound TCP I-D. When we finish this, the ICCRG is also going to do the same for CUBIC and the CUBIC I-D, and other experimental congestion control proposals that come to TCPM. In Philadelphia, we discovered that we didn't know what level of review TCPM desired from the ICCRG. We have been looking at Compound TCP since last summer, but this review incorporates several independent efforts at implementation, experimentation, and simulation (i.e. not just document review). The delay involved in this may be greater than what people bringing congestion control proposals to the IETF would like. It can be difficult enough to get them to bring the proposals here in the first place; as history shows, they can put code into their operating systems and widely deploy without the help of the IETF. My question for TCPM is: Would TCPM participants rather have a "short" review from the ICCRG, on the order of 4 months, that considers the I-D in question and any immediately-available supporting materials, OR would TCPM rather have a "long" review from the ICCRG, perhaps a year, that has a very thorough investigation behind it. Or something else completely. The short review may have to hedge its conclusions with a list of unknowns, but it would specifically identify these, whereas the long review may have less unknowns. As an example, in the Compound TCP review, we have an open question about how it is affected in wireless environments. As a TCPM participant myself, I personally prefer the "short" review to keep proposals to TCPM from spending more time in ICCRG than they do in TCPM :). _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 28 07:59:32 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB1628C96D; Fri, 28 Mar 2008 07:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.797 X-Spam-Level: X-Spam-Status: No, score=-100.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 laQXPq-zKCD1; Fri, 28 Mar 2008 07:59:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD63B28C961; Fri, 28 Mar 2008 07:59:30 -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 4B07628C954 for ; Fri, 28 Mar 2008 07:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 QrYqsCS26AYu for ; Fri, 28 Mar 2008 07:59:29 -0700 (PDT) Received: from flyer.cs.umd.edu (flyer.cs.umd.edu [128.8.128.178]) by core3.amsl.com (Postfix) with ESMTP id 1D82D28C961 for ; Fri, 28 Mar 2008 07:59:29 -0700 (PDT) Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by flyer.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id m2SExkCp018759; Fri, 28 Mar 2008 10:59:46 -0400 Received: from loompa.cs.umd.edu (localhost [127.0.0.1]) by loompa.cs.umd.edu (8.13.8+Sun/8.12.5) with ESMTP id m2SExRH8012799; Fri, 28 Mar 2008 10:59:27 -0400 (EDT) Received: (from capveg@localhost) by loompa.cs.umd.edu (8.13.8+Sun/8.13.8/Submit) id m2SExQMT012798; Fri, 28 Mar 2008 10:59:26 -0400 (EDT) Date: Fri, 28 Mar 2008 10:59:26 -0400 From: Rob Sherwood To: Caitlin Bestler Message-ID: <20080328145926.GI9776@cs.umd.edu> References: <200803260029.33658.v13@v13.gr> <20080326202501.GQ24842@cs.umd.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77034431B9@nekter> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77034431B9@nekter> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: tcpm@ietf.org Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-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 On Thu, Mar 27, 2008 at 07:14:44PM -0400, Caitlin Bestler wrote: > On very high speed links the NIC and/or driver has very little > choice but to implement one or more strategies to reduce the number > of interactions with the TCP consumer. Delivering each TCP segment > as soon as it is deliverable is not a viable option. > > These techniques could include interrupt coalescing, Large Receive > Offload, TCP offload and others. Large Receive Offload in particular > will be negatively impacted whenever the TCP sender does not faithfully > send entire messages in order and as promptly as the TCP congestion > control algorithms expect. LRO seeks to reduce the number of distinct > notifications required to deliver a sequence of TCP Segments for the > same connection, but in a manner that minimizes latency delays. > > When a gap indicates a lost packet the answer is simple, aggregate > what you have and deliver it. When a gap really means that the sender > is testing you then you still aggregate what you have and deliver it. > And then deliver the deliberately mis-ordered segment separately. Again, I think we have missed each other's point here. I think you are over estimating the _frequency_ that the test need be applied. How often the test is applied is a local decision made by the sender, in a trade off between efficiency and how pro-actively attackers are detected. My intuition as to why the test has such low over head is that it is applied less frequently then the regular packet loss rate (caused by congestion and the TCP saw tooth) so it does not increase the apparent packet loss rate significantly. Applied to your high-speed connections, this means that the rate of notifications between the layers would not increase significantly either. Further, the parameters for how often the test is applied are tunable: my experiments recommend skipping a segment once every 1-200 segments, which, for for the machines I had available to me, seemed to be a reasonable compromise between overhead and detection. The higher rate connections that you speak of may be better suited with different parameters: skipping a segment every 1-2000 or something similar. In short, I don't see how you can say that this solution is too inefficient; one can reduce the overhead of the test arbitrarily ( at the cost of reduced detection), > Indeed, if a sender engaged in deliberate TCP segment misordering > on a regular basis it could be considered a Denial-of-service attack. I believe that the security implications of this design are independent of the test I've proposed here. > This is something that can very easily be solved at the application > layer, by simply requiring the application layer to periodically > echo an application layer cookie back to the sender. A trivial AJAX > script could handle this without a single change to the TCP layer. > Using timestamps would also probably work. I guess this is another argument that I don't understand: you're saying it's better to changes all applications individually than solve this in one single place? I agree that adding a challenge-response to all applications would solve the problem, but it assumes modifying the entire world several times over: all applications * all clients * all servers. I just don't see how that is feasible - to say nothing of having to do a per-application analysis of what challenge response is best for the least amount of overhead. > And if the client was > unwilling to provide these echoes, just limit the bandwidth that > you will provide to them. As I mention in my previous mail, using "each host limits the bandwidth each connection gets", even as a fall back for compatibility, does not stop the attack. The attacker can simply target more victims to generate the same aggregated amount of traffic. > As for the "network" implications, this attack is a very poor > candidate for a successful DoS attack because it requires the > attacker to saturate a link that actually leads to them. The > pattern of the attack would be easily detected, and once detected > the destination IP address is easily traceable. Assuming the source ISP was responsive, this might work. But, I contend that most operators looking at the traffic patterns would assume that the attack was backwards, i.e., that it was the victims targeting the attacker. I don't believe that the actions that an operator would be likely to take to stop the mistaken backwards attack (blocking traffic from victim to attacker) would stop the actual attack. This attack works (with reduced efficiency) when the attacker is totally blind with respect to the victims traffic. But yes, IF the source ISP cared, IF they detect the attack, and IF they do the right thing by blocking the senders Acks, then the attack would stop for that one attacker. It just seems like a lot of "if"'s and a lot of dependence on other people doing the right thing when it is your network that is congested. > Work in the IEEE's Data Center Bridging task group should lead to > reduction or elimination of congestion drops within IP subnets. > That means that TCP handling optimizations in NICs, drivers or > TCP stacks that expect in-order delivery will be even more effective. > > The NICs and Bridges supporting these techniques will be going through > a lot of extra work to provide largely lossless and in-order delivery > of TCP segments. Deliberately sending them in the wrong order borders > on being ungrateful. At least from your description here, it would seem that they have DoS implications independent of this test. I will have to read up on these issues, thank you for pointing them out. - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm