From tcpm-bounces@ietf.org Thu Sep 06 16:16:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITNkr-0000YH-Vr; Thu, 06 Sep 2007 16:15:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITNkl-0000Ws-76; Thu, 06 Sep 2007 16:15:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITNkk-0001Dj-Q9; Thu, 06 Sep 2007 16:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 7E13C2AB74; Thu, 6 Sep 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ITNkk-0007qh-6D; Thu, 06 Sep 2007 16:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 06 Sep 2007 16:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-rfc2581bis-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Congestion Control Author(s) : M. Allman, et al. Filename : draft-ietf-tcpm-rfc2581bis-03.txt Pages : 16 Date : 2007-9-6 This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-rfc2581bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-rfc2581bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-6152846.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-rfc2581bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-rfc2581bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-6152846.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Thu Sep 06 17:54:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITPHL-0006p9-KU; Thu, 06 Sep 2007 17:52:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITPHK-0006p3-HJ for tcpm@ietf.org; Thu, 06 Sep 2007 17:52:46 -0400 Received: from smtpoutm.mac.com ([17.148.16.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITPHI-0004v0-DH for tcpm@ietf.org; Thu, 06 Sep 2007 17:52:46 -0400 Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpoutm.mac.com (Xserve/smtpout013/MantshX 4.0) with ESMTP id l86LqhNs021888; Thu, 6 Sep 2007 14:52:43 -0700 (PDT) Received: from [137.226.12.154] (dhcp154.informatik.rwth-aachen.de [137.226.12.154]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id l86Lq3Yi000817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Sep 2007 14:52:41 -0700 (PDT) In-Reply-To: <46C5CFA1.3090603@isi.edu> References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <46C5CFA1.3090603@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <443EB15A-FBED-4325-AD04-CCC39E989DDE@mac.com> Content-Transfer-Encoding: 7bit From: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages Date: Thu, 6 Sep 2007 23:52:26 +0200 To: Joe Touch X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On 2007/08/17 , at 18:41, Joe Touch wrote: > AFAIK, congestion control response to in-band messages (ACKs) and > timeouts (implied loss, as TCP interprets it), as well as to some new > fields (ECN, etc.) which are carried in the same packets. > > Reactions to external congestion signals - ICMP source quench > (which has > been informally deprecated a while ago, but has not been documented as > such yet) or otherwise - would constitute another opportunity for a > DOS > attack, and seem like a bad idea to encourage. I am note sure your security concerns really apply :) If the bad user controls the forwarding node, there is no need to rely on ICMP message to cause harm. Instead, just dropping random segments would do the job. If the bad user is off the forwarding node, she would need (as usual) guess port and sequence numbers. If she is able to guess right, she might as well opt to send forged ACK dupacks to cause harm, or for an ECN capable transport just one ECE marked ACK. Overall, it seems to me that there don't arise additional attack opportunities if there was congestion control on ICMP messages. But maybe I am missing something? Thanks again, Daniel _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 06 18:15:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITPc6-00056M-1k; Thu, 06 Sep 2007 18:14:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITPc2-00055N-SY for tcpm@ietf.org; Thu, 06 Sep 2007 18:14:11 -0400 Received: from smtpoutm.mac.com ([17.148.16.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITPc2-00011c-BR for tcpm@ietf.org; Thu, 06 Sep 2007 18:14:10 -0400 Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpoutm.mac.com (Xserve/smtpout012/MantshX 4.0) with ESMTP id l86ME9wJ004370; Thu, 6 Sep 2007 15:14:09 -0700 (PDT) Received: from [137.226.12.154] (dhcp154.informatik.rwth-aachen.de [137.226.12.154]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id l86ME40s029239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Sep 2007 15:14:07 -0700 (PDT) In-Reply-To: <20070817162542.GA2511@hut.isi.edu> References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <20070817162542.GA2511@hut.isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4AD719E5-AF65-4D4C-8BE8-B070793F69C3@mac.com> Content-Transfer-Encoding: 7bit From: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages Date: Fri, 7 Sep 2007 00:13:51 +0200 To: Ted Faber X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On 2007/08/17 , at 18:25, Ted Faber wrote: > On Fri, Aug 17, 2007 at 06:06:55PM +0200, Daniel Schaffrath wrote: >> Dear Community, >> >> I was wondering if there are any recommendations regarding congestion >> control in face of ICMP (host/network) unreachable messages. If I am >> not mistaken there is nothing in the various TCPM documents... nor in >> any RFC. >> >> Maybe you have any pointers? > > Sure. If the code in the destination unreachable message is 2-4 abort > the connection. Otherwise, don't. RFC 1122. Ok... however, aborting a connection seems somewhat a bit too harsh congestion control to me :) > I wouldn't use ICMP reachability information in congestion control, > and I don't believe that any standard requires an implementer to do > so. > If packets aren't being delivered, the sending endpoint(s) will slow > down pretty dramatically, pretty quickly without intervention. A > retransmisson timeout puts the endpoint into slow start. Yes. And that exactly what I am after. Don't you think that this a bit to conservative? Especially if you consider exponential back-off. I mean, if TCP retransmits after RTO and gets no reply, this indicates severe congestion and back-off is fine. But if it gets an ICMP unreachable message again, this might allow a less conservative behavior? Another thing is that RTO needs to expire to reach slow-start recovery. If my understanding of RFC 1122 is correct, it's still standard compliant to continue sending after having received the first appropriate ICMP message. Maybe that's a bit too aggressive (as opposed to slow-start recovery after an "ICMP induced" RTO). Thank you, Daniel _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 06 20:46:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITRxG-0003nK-RW; Thu, 06 Sep 2007 20:44:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITRxG-0003nE-6W for tcpm@ietf.org; Thu, 06 Sep 2007 20:44:14 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITRxF-0005Gm-Fs for tcpm@ietf.org; Thu, 06 Sep 2007 20:44:14 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l870hZMW028672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Sep 2007 17:43:35 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l870hZa0050569; Thu, 6 Sep 2007 17:43:35 -0700 (PDT) (envelope-from faber) Date: Thu, 6 Sep 2007 17:43:35 -0700 From: Ted Faber To: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages Message-ID: <20070907004335.GB48227@hut.isi.edu> References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <20070817162542.GA2511@hut.isi.edu> <4AD719E5-AF65-4D4C-8BE8-B070793F69C3@mac.com> Mime-Version: 1.0 In-Reply-To: <4AD719E5-AF65-4D4C-8BE8-B070793F69C3@mac.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1238649063==" Errors-To: tcpm-bounces@ietf.org --===============1238649063== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Acting in no official capacity, I say: On Fri, Sep 07, 2007 at 12:13:51AM +0200, Daniel Schaffrath wrote: >=20 > On 2007/08/17 , at 18:25, Ted Faber wrote: >=20 > >On Fri, Aug 17, 2007 at 06:06:55PM +0200, Daniel Schaffrath wrote: > >>Dear Community, > >> > >>I was wondering if there are any recommendations regarding congestion > >>control in face of ICMP (host/network) unreachable messages. If I am > >>not mistaken there is nothing in the various TCPM documents... nor in > >>any RFC. > >> > >>Maybe you have any pointers? > > > >Sure. If the code in the destination unreachable message is 2-4 abort > >the connection. Otherwise, don't. RFC 1122. > Ok... however, aborting a connection seems somewhat a bit too harsh =20 > congestion control to me :) Assuming you believe these are valid messages, those codes indicate that the entity you want to talk to is not there or has gone away and isn't coming back. The sender is required to terminate the connection because the network has told it that the receiver cannot be reached and that further packets will not be delivered. Sending any packets under those conditions will just take up space until they're dropped. >=20 > >I wouldn't use ICMP reachability information in congestion control, > >and I don't believe that any standard requires an implementer to do =20 > >so. > >If packets aren't being delivered, the sending endpoint(s) will slow > >down pretty dramatically, pretty quickly without intervention. A > >retransmisson timeout puts the endpoint into slow start. > Yes. And that exactly what I am after. Don't you think that this a =20 > bit to conservative? Especially if you consider exponential back-off. =20 > I mean, if TCP retransmits after RTO and gets no reply, this =20 > indicates severe congestion and back-off is fine. But if it gets an =20 > ICMP unreachable message again, this might allow a less conservative =20 > behavior? Huh? If TCP has gotten to the point where a retransmission timer has gone off not only has the transmission of the packet to be retransmitted failed, but enough other packets have been lost that the fast retransmit algorithm (3 dupacks) has also not happened (yes, the window needs to have grown to 4...). In short, there's something very wrong with the communication between the endpoints, and drastic action is called for. Specifically, the sender acts as though the connection is almost new - window is as small as possible and the ssthresh is halved. Your text above sounds like you're saying that if a sender has heard the network say that there's a connectivity problem between the sender and receiver (ICMP destination unreachable) the sender is entitled to react less conservatively, even though all the evidence is that the link is congested. I don't understand that logic at all. Even if you believe that the ICMP messages indicate a transient condition and that the connection to the receiver will eventually be restored, the sender's best information is that something in the network is confused about how to the destination (ICMP unreachable) and that the receiver is unable to communicate with the sender (no ACKs for an RTO). All evidence is that your packets are doing no good and possible harm (congesting links over which they're being wrongly routed). Explain to me why ICMP messages indicating that your packets are not being delivered indicate you should not slow down. >=20 > Another thing is that RTO needs to expire to reach slow-start =20 > recovery. If my understanding of RFC 1122 is correct, it's still =20 > standard compliant to continue sending after having received the =20 > first appropriate ICMP message. Maybe that's a bit too aggressive (as =20 > opposed to slow-start recovery after an "ICMP induced" RTO). I believe your understanding of RFC 1122 is incorrect. I don't believe that receiving an ICMP message of any kind has any effect on the TCP congestion control algorithms whatsoever (other than aborting the connection in the case above). ICMP messages are not part of a TCP connection, and receiving one does not count as receiveing a TCP packet, much less an ACK. After all, an ICMP message may well be coming from an intermediate gateway. What text have I missed? --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG4J63aUz3f+Zf+XsRAlmIAJ438oTH1EIxmJxA1uCptR8oVFWetACffVli VO4Ojemdr05+0X4eFI9z/2Q= =QQW4 -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- --===============1238649063== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1238649063==-- From tcpm-bounces@ietf.org Fri Sep 07 10:15:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITeaj-0006zi-Eh; Fri, 07 Sep 2007 10:13:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITeah-0006zR-Ix for tcpm@ietf.org; Fri, 07 Sep 2007 10:13:47 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITeag-0001bm-9t for tcpm@ietf.org; Fri, 07 Sep 2007 10:13:47 -0400 Received: from [127.0.0.1] ([128.9.176.75]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l87EDUOt013139; Fri, 7 Sep 2007 07:13:31 -0700 (PDT) Message-ID: <46E15C78.4080706@isi.edu> Date: Fri, 07 Sep 2007 07:13:12 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <46C5CFA1.3090603@isi.edu> <443EB15A-FBED-4325-AD04-CCC39E989DDE@mac.com> In-Reply-To: <443EB15A-FBED-4325-AD04-CCC39E989DDE@mac.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0500528755==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0500528755== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig52017D21D8FA2E76E206D17B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig52017D21D8FA2E76E206D17B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniel Schaffrath wrote: >=20 > On 2007/08/17 , at 18:41, Joe Touch wrote: >=20 >> AFAIK, congestion control response to in-band messages (ACKs) and >> timeouts (implied loss, as TCP interprets it), as well as to some new >> fields (ECN, etc.) which are carried in the same packets. >> >> Reactions to external congestion signals - ICMP source quench (which h= as >> been informally deprecated a while ago, but has not been documented as= >> such yet) or otherwise - would constitute another opportunity for a DO= S >> attack, and seem like a bad idea to encourage. > > I am note sure your security concerns really apply :) If the bad user > controls the forwarding node, there is no need to rely on ICMP message > to cause harm. Instead, just dropping random segments would do the job.= > If the bad user is off the forwarding node, she would need (as usual) > guess port and sequence numbers.=20 Only port numbers. Sequence numbers strictly don't matter for ICMPs. > If she is able to guess right, she > might as well opt to send forged ACK dupacks to cause harm, or for an > ECN capable transport just one ECE marked ACK. ICMPs don't need to come from the endpoint IP address, i.e., address verification will prevent spoofed ACKs, but cannot prevent ICMPs, since the latter need not have spoofed source addresses. > Overall, it seems to me that there don't arise additional attack > opportunities if there was congestion control on ICMP messages. Basically the above; ICMPs don't need to have forged source addresses, but in-band attacks do. Joe --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enig52017D21D8FA2E76E206D17B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG4Vx4E5f5cImnZrsRAiQjAJ9MOvGfRBWQBRaB+s1wx9/jsc0spwCfeEOF Mr1KYnM5BRf4UdKaYHarNaM= =S/da -----END PGP SIGNATURE----- --------------enig52017D21D8FA2E76E206D17B-- --===============0500528755== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0500528755==-- From tcpm-bounces@ietf.org Sat Sep 08 02:03:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITtON-00050e-HL; Sat, 08 Sep 2007 02:02:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITtOM-00050S-CI for tcpm@ietf.org; Sat, 08 Sep 2007 02:02:02 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITtOL-0004cS-OF for tcpm@ietf.org; Sat, 08 Sep 2007 02:02:02 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8861rnx024267; Sat, 8 Sep 2007 09:01:53 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Sep 2007 09:01:52 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Sep 2007 09:01:51 +0300 Received: from [192.168.255.2] (essapo-nirac253229.europe.nokia.com [10.162.253.229]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8861oKN032354; Sat, 8 Sep 2007 09:01:50 +0300 Mime-Version: 1.0 (Apple Message framework v752.3) To: iccrg , tcpm@ietf.org Message-Id: References: <46E0F0E8.8040000@swin.edu.au> From: Lars Eggert Date: Sat, 8 Sep 2007 09:01:46 +0300 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 Sep 2007 06:01:52.0039 (UTC) FILETIME=[C057BB70:01C7F1DD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Subject: [tcpm] Fwd: [e2e] Logging active TCP details in FreeBSD 5, 6 and 7 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1646659044==" Errors-To: tcpm-bounces@ietf.org --===============1646659044== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14-470709307; protocol="application/pkcs7-signature" --Apple-Mail-14-470709307 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed FYI Begin forwarded message: > From: "ext grenville armitage" > Date: September 7, 2007 9:34:16 GMT+03:00 > To: end2end > Subject: [e2e] Logging active TCP details in FreeBSD 5, 6 and 7 > > All, > > On the off chance this is of general interest, I'd like to let > people know of a FreeBSD kernel module we've developed for > logging various TCP state variables in a running kernel > while sessions are active. > > Called SIFTR ("sifter"), we built this for our own research into > precisely how a FreeBSD TCP stack behaves when faced with real > and artificial (e.g. dummynet) paths. Figured it might also be > of interest to others. > > See http://caia.swin.edu.au/urp/newtcp/tools.html (under SIFTR) > for a readme, changelog and tarball. The authors would love to get > feedback from anyone trying it out. (SIFTR has been developed and > tested mostly under FreeBSD 6.2, but we believe it'll be stable > under 5.x and 7.x too.) > > cheers, > gja > --Apple-Mail-14-470709307 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA5MDgwNjAxNDdaMCMGCSqGSIb3DQEJBDEWBBTZSommPtiH4DJU 6+jBiJUOJtNI4zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAjxfISg05QDn450qBBtZGdbt7cyr01xikR2hFn9Ctyjeq11bARA// 5HtZBgvsxvX3bNMHzLcKzTii4NhdWrkdjEj6847dBdSqXGnjZeDAXwXGL4j6GfpokJsNC782m+Wt K60HXGDL6V6BAPp9JrLxmOcCDYrpcuQ9Ba9qhnYZbbR8bYdAl0zd8xogq/nCDcEsH10aJKjPhSKf 6lI0JXdC1jtPx6EnRiJv/Tv8182cFTKLoQhFiPFJ5IyCqF8brbXNcMI+5TqE+0QS7WjXK2Xk/A5z cUNSlrCWRfXR0fNcfJXB+wNrFK1OV+Fbw8QwnKiuVYldk/r6Ys/JvOssc1p1kQAAAAAAAA== --Apple-Mail-14-470709307-- --===============1646659044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1646659044==-- From tcpm-bounces@ietf.org Wed Sep 12 11:41:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUJH-000401-Ah; Wed, 12 Sep 2007 11:39:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUJF-0003z3-Cy; Wed, 12 Sep 2007 11:39:21 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVUJD-0002B0-UC; Wed, 12 Sep 2007 11:39:21 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8CFd6H9018632; Wed, 12 Sep 2007 18:39:15 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 18:38:45 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 18:38:45 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 18:38:44 +0300 Received: from [172.21.39.198] (esdhcp039198.research.nokia.com [172.21.39.198]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8CFchfb023671; Wed, 12 Sep 2007 18:38:43 +0300 Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Date: Wed, 12 Sep 2007 18:38:38 +0300 To: tsvwg WG X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Sep 2007 15:38:44.0211 (UTC) FILETIME=[00750C30:01C7F553] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: tcpm@ietf.org, draft-larsen-tsvwg-port-randomization@tools.ietf.org, DCCP mailing list Subject: [tcpm] consensus call: draft-larsen-tsvwg-port-randomization to WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsvwg WG List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1998048857==" Errors-To: tcpm-bounces@ietf.org --===============1998048857== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-110-850921612; protocol="application/pkcs7-signature" --Apple-Mail-110-850921612 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, regarding http://tools.ietf.org/html/draft-larsen-tsvwg-port- randomization, there was quite a bit of discussion around this draft during the summer. My personal take is that I saw more positive than negative comments, but I'd like to confirm this. I'd hence like to start a consensus call on whether we want to take this document to be the basis for a standards-track work item in TSVWG that will recommend a randomization scheme for operating systems allocation of source ports. Because this scheme will cover all our transport protocols, I'm CC'ing the DCCP and TCPM working groups. This consensus call will run for two weeks, until September 28. Please comment on the tsvwg@ietf.org list (reply-to set accordingly), even if you have already commented be on this draft in the past. To make it easy for your chairs, please start your email by choosing ONE of the options below, followed by any detailed comments you'd like to make: (1) TSVWG should take on this work item, with this document as the basis (2) TSVWG should take on this work item, but NOT with this document as the basis (3) TSVWG should NOT take on this work item (4) don't care Thanks, Lars --Apple-Mail-110-850921612 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA5MTIxNTM4MzlaMCMGCSqGSIb3DQEJBDEWBBT9rfhVTYmK1xws 9bcRu3Y133dz3zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAgcMcnevVZw5EdmUE0LFoutUX9OBK6f2IBF4p7lrLV1wKtMdC4nNP aM2easRxnk4wwc2T16eaCqSVHrR/74HT7R8nFiXvcsXRlJakkvpC3C3F02QINwel6OiEnd7h2g1r dVX6wiTZHD+yD5FNAkqcjPHQK0f67eHQQCuJwMUEz6nvHbOptHMU2VvByC3nB7BdlR9bqXy9QwOM BR7eWOTnhGVPYJt7bUk0wigDk0M+WeDKyAfPTgy3ITNqYTotMcbOKUBnwJhN5dvmNhqvUqsRlcXD M7QE8j7pcEjz4DWkOIRe1uxuOEPpboukJ2hvkc3EggImjyEybLqx7AQ4GF44QgAAAAAAAA== --Apple-Mail-110-850921612-- --===============1998048857== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1998048857==-- From tcpm-bounces@ietf.org Wed Sep 12 14:25:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWsR-0006jg-5D; Wed, 12 Sep 2007 14:23:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWsQ-0006ja-Jw for tcpm@ietf.org; Wed, 12 Sep 2007 14:23:50 -0400 Received: from smtpoutm.mac.com ([17.148.16.78]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVWsP-0003ol-Nl for tcpm@ietf.org; Wed, 12 Sep 2007 14:23:50 -0400 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpoutm.mac.com (Xserve/smtpout015/MantshX 4.0) with ESMTP id l8CINmGa011821; Wed, 12 Sep 2007 11:23:48 -0700 (PDT) Received: from [137.226.12.157] (dhcp157.informatik.rwth-aachen.de [137.226.12.157]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l8CINf0F016332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Sep 2007 11:23:46 -0700 (PDT) In-Reply-To: <20070907004335.GB48227@hut.isi.edu> References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <20070817162542.GA2511@hut.isi.edu> <4AD719E5-AF65-4D4C-8BE8-B070793F69C3@mac.com> <20070907004335.GB48227@hut.isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages Date: Wed, 12 Sep 2007 20:23:32 +0200 To: Ted Faber X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On 2007/09/07 , at 02:43, Ted Faber wrote: > Acting in no official capacity, I say: Sorry, I don't get this. > On Fri, Sep 07, 2007 at 12:13:51AM +0200, Daniel Schaffrath wrote: >> >> On 2007/08/17 , at 18:25, Ted Faber wrote: >> >>> On Fri, Aug 17, 2007 at 06:06:55PM +0200, Daniel Schaffrath wrote: >>>> Dear Community, >>>> >>>> I was wondering if there are any recommendations regarding >>>> congestion >>>> control in face of ICMP (host/network) unreachable messages. If >>>> I am >>>> not mistaken there is nothing in the various TCPM documents... >>>> nor in >>>> any RFC. >>>> >>>> Maybe you have any pointers? >>> >>> Sure. If the code in the destination unreachable message is 2-4 >>> abort >>> the connection. Otherwise, don't. RFC 1122. >> Ok... however, aborting a connection seems somewhat a bit too harsh >> congestion control to me :) > > Assuming you believe these are valid messages, those codes indicate > that > the entity you want to talk to is not there or has gone away and isn't > coming back. The sender is required to terminate the connection > because > the network has told it that the receiver cannot be reached and that > further packets will not be delivered. Sending any packets under > those > conditions will just take up space until they're dropped. I was actually joking about the term "congestion control". To me _congestion_ control is about how much to send and not whether to send at all. Of course, I understand that the latter is included in the former... in some way :) >>> I wouldn't use ICMP reachability information in congestion control, >>> and I don't believe that any standard requires an implementer to do >>> so. >>> If packets aren't being delivered, the sending endpoint(s) will slow >>> down pretty dramatically, pretty quickly without intervention. A >>> retransmisson timeout puts the endpoint into slow start. >> Yes. And that exactly what I am after. Don't you think that this a >> bit to conservative? Especially if you consider exponential back-off. >> I mean, if TCP retransmits after RTO and gets no reply, this >> indicates severe congestion and back-off is fine. But if it gets an >> ICMP unreachable message again, this might allow a less conservative >> behavior? > > Huh? > > If TCP has gotten to the point where a retransmission timer has > gone off > not only has the transmission of the packet to be retransmitted > failed, > but enough other packets have been lost that the fast retransmit > algorithm (3 dupacks) has also not happened (yes, the window needs to > have grown to 4...). In short, there's something very wrong with the > communication between the endpoints, and drastic action is called for. > Specifically, the sender acts as though the connection is almost new - > window is as small as possible and the ssthresh is halved. > > Your text above sounds like you're saying that if a sender has > heard the > network say that there's a connectivity problem between the sender and > receiver (ICMP destination unreachable) the sender is entitled to > react > less conservatively, even though all the evidence is that the link is > congested. From my understanding the evidence is that just some link is (was) not working and that is not the same as a link is congested. Even, there is some slight indication that there is no congestion in the network (or at least the very part of it) as the ICMP message (as well as the segment eliciting the ICMP message) was not dropped and got to the TCP source. > I don't understand that logic at all. Even if you believe that the > ICMP > messages indicate a transient condition and that the connection to the > receiver will eventually be restored, the sender's best information is > that something in the network is confused about how to the destination > (ICMP unreachable) and that the receiver is unable to communicate with > the sender (no ACKs for an RTO). All evidence is that your packets > are > doing no good and possible harm (congesting links over which they're > being wrongly routed). > > Explain to me why ICMP messages indicating that your packets are not > being delivered indicate you should not slow down. I am not saying you shouldn't slow down. After RTO of course you should reset cwnd and halve ssthresh. I was just thinking of skipping (or delaying) doubling RTO if the retransmission after RTO does not simply vanish in the network but is replied to with an ICMP (host/ net) unreachable message. This seems reasonable to me if my above finding is true. >> Another thing is that RTO needs to expire to reach slow-start >> recovery. If my understanding of RFC 1122 is correct, it's still >> standard compliant to continue sending after having received the >> first appropriate ICMP message. Maybe that's a bit too aggressive (as >> opposed to slow-start recovery after an "ICMP induced" RTO). > > I believe your understanding of RFC 1122 is incorrect. I don't > believe > that receiving an ICMP message of any kind has any effect on the TCP > congestion control algorithms whatsoever (other than aborting the > connection in the case above). ICMP messages are not part of a TCP > connection, and receiving one does not count as receiveing a TCP > packet, much less an ACK. After all, an ICMP message may well be > coming > from an intermediate gateway. Maybe my paragraph above was not clear. I am not saying that RFC 1122 suggests ICMP messages to have effect on cwnd. I am saying that from my understanding RFC 1122 allows a TCP to continue sending segments after having received an ICMP host/net unreachable message. This seems to me as a waste of bandwidth as the arrival of the ICMP message just indicated that right now there is no route to the destination. Doesn't that sound reasonable? But maybe continuing sending makes sense together with some other RFC I am not aware of but someone else on the list. > What text have I missed? I don't know. How come you feel you missed some text?? Thanks again! Daniel Schaffrath _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 12 14:25:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWsO-0006j9-V7; Wed, 12 Sep 2007 14:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWsN-0006iX-Fj for tcpm@ietf.org; Wed, 12 Sep 2007 14:23:47 -0400 Received: from smtpoutm.mac.com ([17.148.16.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVWsM-0006Lp-2o for tcpm@ietf.org; Wed, 12 Sep 2007 14:23:47 -0400 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpoutm.mac.com (Xserve/smtpout015/MantshX 4.0) with ESMTP id l8CINjhE011781; Wed, 12 Sep 2007 11:23:45 -0700 (PDT) Received: from [137.226.12.157] (dhcp157.informatik.rwth-aachen.de [137.226.12.157]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l8CINf0E016332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Sep 2007 11:23:43 -0700 (PDT) In-Reply-To: <46E15C78.4080706@isi.edu> References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <46C5CFA1.3090603@isi.edu> <443EB15A-FBED-4325-AD04-CCC39E989DDE@mac.com> <46E15C78.4080706@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <15CFCCD8-0CDD-4033-9B83-7C42AEEDD88A@mac.com> Content-Transfer-Encoding: 7bit From: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages Date: Wed, 12 Sep 2007 20:23:27 +0200 To: Joe Touch X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On 2007/09/07 , at 16:13, Joe Touch wrote: > Daniel Schaffrath wrote: >> On 2007/08/17 , at 18:41, Joe Touch wrote: >>> AFAIK, congestion control response to in-band messages (ACKs) and >>> timeouts (implied loss, as TCP interprets it), as well as to some >>> new >>> fields (ECN, etc.) which are carried in the same packets. >>> >>> Reactions to external congestion signals - ICMP source quench >>> (which has >>> been informally deprecated a while ago, but has not been >>> documented as >>> such yet) or otherwise - would constitute another opportunity for >>> a DOS >>> attack, and seem like a bad idea to encourage. >> >> I am note sure your security concerns really apply :) If the bad user >> controls the forwarding node, there is no need to rely on ICMP >> message >> to cause harm. Instead, just dropping random segments would do the >> job. >> If the bad user is off the forwarding node, she would need (as usual) >> guess port and sequence numbers. > > Only port numbers. Sequence numbers strictly don't matter for ICMPs. But that is under way, if I am not mistaken (draft-ietf-tcpm-icmp- attacks-02). And Linux for instance already implements it... >> If she is able to guess right, she >> might as well opt to send forged ACK dupacks to cause harm, or for an >> ECN capable transport just one ECE marked ACK. > > ICMPs don't need to come from the endpoint IP address, i.e., address > verification will prevent spoofed ACKs, but cannot prevent ICMPs, > since > the latter need not have spoofed source addresses. Ok, but if a router is (potentially) able to check for spoofed IP source addresses it could as well check for spoofed/illegal ICMP payloads (which contain both IP addresses) . Isn't that true? Apart from that: how common is it to drop spoofed datagrams? It's probably a idealistic assumption, isn't it? [...] Thank you, Daniel Schaffrath _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 12 23:03:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVexl-0004w2-UY; Wed, 12 Sep 2007 23:01:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVexk-0004sj-Ov for tcpm@ietf.org; Wed, 12 Sep 2007 23:01:52 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVexj-0008Cf-Fq for tcpm@ietf.org; Wed, 12 Sep 2007 23:01:52 -0400 Received: from [127.0.0.1] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8D31bjl021468; Wed, 12 Sep 2007 20:01:38 -0700 (PDT) Message-ID: <46E8A7FE.6000404@isi.edu> Date: Wed, 12 Sep 2007 20:01:18 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <46C5CFA1.3090603@isi.edu> <443EB15A-FBED-4325-AD04-CCC39E989DDE@mac.com> <46E15C78.4080706@isi.edu> <15CFCCD8-0CDD-4033-9B83-7C42AEEDD88A@mac.com> In-Reply-To: <15CFCCD8-0CDD-4033-9B83-7C42AEEDD88A@mac.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0163090937==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0163090937== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig15910892145C85BBFDBB6278" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig15910892145C85BBFDBB6278 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Daniel, Daniel Schaffrath wrote: >=20 > On 2007/09/07 , at 16:13, Joe Touch wrote: >> Daniel Schaffrath wrote: >>> On 2007/08/17 , at 18:41, Joe Touch wrote: >>>> AFAIK, congestion control response to in-band messages (ACKs) and >>>> timeouts (implied loss, as TCP interprets it), as well as to some ne= w >>>> fields (ECN, etc.) which are carried in the same packets. >>>> >>>> Reactions to external congestion signals - ICMP source quench (which= >>>> has >>>> been informally deprecated a while ago, but has not been documented = as >>>> such yet) or otherwise - would constitute another opportunity for a = DOS >>>> attack, and seem like a bad idea to encourage. >>> >>> I am note sure your security concerns really apply :) If the bad user= >>> controls the forwarding node, there is no need to rely on ICMP messag= e >>> to cause harm. Instead, just dropping random segments would do the jo= b. >>> If the bad user is off the forwarding node, she would need (as usual)= >>> guess port and sequence numbers. >> >> Only port numbers. Sequence numbers strictly don't matter for ICMPs. > But that is under way, if I am not mistaken > (draft-ietf-tcpm-icmp-attacks-02). And Linux for instance already > implements it... I've already spoken about this at previous IETFs and on this list. The basic summary: - the network is under no obligation to respond with ICMPs within one RTT= - as a result, checking to ensure that ICMPs are in-window is incorrect as it will drop legitimate responses - or worse, interpret them as attack= s The fact that an I-D remains on this point and that Linux implements it does not change the above. >>> If she is able to guess right, she >>> might as well opt to send forged ACK dupacks to cause harm, or for an= >>> ECN capable transport just one ECE marked ACK. >> >> ICMPs don't need to come from the endpoint IP address, i.e., address >> verification will prevent spoofed ACKs, but cannot prevent ICMPs, sinc= e >> the latter need not have spoofed source addresses. > > Ok, but if a router is (potentially) able to check for spoofed IP sourc= e > addresses it could as well check for spoofed/illegal ICMP payloads > (which contain both IP addresses) . Isn't that true? Routers can check for spoofed addresses as they enter protected regions of the Internet; if there's a hole in that 'fence' however, packets can leak in. Once in, they can't necessarily be checked for spoofed addresses unless they're authenticated, and most are not. > Apart from that: how common is it to drop spoofed datagrams? It's > probably a idealistic assumption, isn't it? In general, yes. You can't assume that spoofed packets are dropped. Joe --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enig15910892145C85BBFDBB6278 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG6Kf/E5f5cImnZrsRAjKEAJ4zmdQWjYFBEPUu2MFnxmdnfUQ5MwCglR61 00W73FopKJoJFsZvKwfadWE= =X/pz -----END PGP SIGNATURE----- --------------enig15910892145C85BBFDBB6278-- --===============0163090937== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0163090937==-- From tcpm-bounces@ietf.org Wed Sep 12 23:17:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVfBL-0005Cd-VU; Wed, 12 Sep 2007 23:15:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVfBL-00057o-Af for tcpm@ietf.org; Wed, 12 Sep 2007 23:15:55 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVfBK-0006rf-LG for tcpm@ietf.org; Wed, 12 Sep 2007 23:15:55 -0400 Received: from [127.0.0.1] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8D3FnWC024191; Wed, 12 Sep 2007 20:15:49 -0700 (PDT) Message-ID: <46E8AB52.9060506@isi.edu> Date: Wed, 12 Sep 2007 20:15:30 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <20070817162542.GA2511@hut.isi.edu> <4AD719E5-AF65-4D4C-8BE8-B070793F69C3@mac.com> <20070907004335.GB48227@hut.isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1203409623==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1203409623== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig10D98710AB640A589B822DB7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig10D98710AB640A589B822DB7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniel Schaffrath wrote: >=20 > On 2007/09/07 , at 02:43, Ted Faber wrote: >=20 >> Acting in no official capacity, I say: > Sorry, I don't get this. Ted is chair of the working group; he's taking that hat off in this reply ;-) =2E.. >> Assuming you believe these are valid messages, those codes indicate th= at >> the entity you want to talk to is not there or has gone away and isn't= >> coming back. The sender is required to terminate the connection becau= se >> the network has told it that the receiver cannot be reached and that >> further packets will not be delivered. Sending any packets under thos= e >> conditions will just take up space until they're dropped. > > I was actually joking about the term "congestion control". To me > _congestion_ control is about how much to send and not whether to send > at all. Of course, I understand that the latter is included in the > former... in some way :) Congestion is "packets that slows down or drops other packets". Packets sent to unavailable ports may have nothing to do with congestion - they don't have to compete for resources. It's not about relieving the network from congestion - congestion control handles that. A good example: UDP has no congestion control, but can generate ICMP responses. =2E.. >> Your text above sounds like you're saying that if a sender has heard t= he >> network say that there's a connectivity problem between the sender and= >> receiver (ICMP destination unreachable) the sender is entitled to reac= t >> less conservatively, even though all the evidence is that the link is >> congested. > > From my understanding the evidence is that just some link is (was) not > working and that is not the same as a link is congested. Even, there is= > some slight indication that there is no congestion in the network (or a= t > least the very part of it) as the ICMP message (as well as the segment > eliciting the ICMP message) was not dropped and got to the TCP source. The ICMP travels on the reverse path; there could be congestion in the forward path. =2E.. >> Explain to me why ICMP messages indicating that your packets are not >> being delivered indicate you should not slow down. > > I am not saying you shouldn't slow down. After RTO of course you should= > reset cwnd and halve ssthresh. I was just thinking of skipping (or > delaying) doubling RTO if the retransmission after RTO does not simply > vanish in the network but is replied to with an ICMP (host/net) > unreachable message. This seems reasonable to me if my above finding is= > true. Host/net unreachable means that you sent some packets along a path that couldn't reach that host/net. That's not to say that other packets wouldn't be delivered properly. It's like hitting a roadblock on the way across town. It doesn't say the endpoint is dead; that's why you don't give up, and also why you need not change your congestion parameters. Finding a bad path could happen by a routing transient - if you get these replies over a RTT, then maybe you give up. Or two RTTs. That's why 1122 doesn't say to ignore these - it says to use them as a hint. They're a hint that something can't be reached - not that there's congestion. =2E.. > Maybe my paragraph above was not clear. I am not saying that RFC 1122 > suggests ICMP messages to have effect on cwnd. I am saying that from my= > understanding RFC 1122 allows a TCP to continue sending segments after= > having received an ICMP host/net unreachable message.=20 Correct. > This seems to me > as a waste of bandwidth as the arrival of the ICMP message just > indicated that right now there is no route to the destination. Doesn't > that sound reasonable? But maybe continuing sending makes sense togethe= r > with some other RFC I am not aware of but someone else on the list. It's consistent within 1122. The message doesn't say there's congestion; it says routing doesn't work for the packet you sent. It may be a waste of bandwidth, but that's not the same as congestion - if you're actually competing for resources others need, your data packet would have been dropped and you wouldn't get an ICMP at all. Getting the ICMP effectively says you are NOT experiencing congestion. Joe --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enig10D98710AB640A589B822DB7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFG6KtSE5f5cImnZrsRAkieAJdeGoBvYUdfH4e6+/U+f0aeAmhHAJ9WFpPA QWOHzHRaDzLx9ld/IEq+jw== =cuqD -----END PGP SIGNATURE----- --------------enig10D98710AB640A589B822DB7-- --===============1203409623== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1203409623==-- From tcpm-bounces@ietf.org Thu Sep 13 20:01:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVycg-0007gK-Ia; Thu, 13 Sep 2007 20:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVyce-0007gF-Oc for tcpm@ietf.org; Thu, 13 Sep 2007 20:01:24 -0400 Received: from smtpoutm.mac.com ([17.148.16.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVycd-0002ad-Fl for tcpm@ietf.org; Thu, 13 Sep 2007 20:01:24 -0400 Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpoutm.mac.com (Xserve/smtpout013/MantshX 4.0) with ESMTP id l8E01N8n008151; Thu, 13 Sep 2007 17:01:23 -0700 (PDT) Received: from [192.168.178.24] (p57a4bdfc.dip0.t-ipconnect.de [87.164.189.252]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id l8E01IE5024754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Sep 2007 17:01:20 -0700 (PDT) In-Reply-To: <46E8A7FE.6000404@isi.edu> References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <46C5CFA1.3090603@isi.edu> <443EB15A-FBED-4325-AD04-CCC39E989DDE@mac.com> <46E15C78.4080706@isi.edu> <15CFCCD8-0CDD-4033-9B83-7C42AEEDD88A@mac.com> <46E8A7FE.6000404@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages Date: Fri, 14 Sep 2007 02:01:00 +0200 To: Joe Touch X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Thanks, Joe, for all the patience. On 2007/09/13 , at 05:01, Joe Touch wrote: > Hi, Daniel, > > Daniel Schaffrath wrote: >> On 2007/09/07 , at 16:13, Joe Touch wrote: >>> Daniel Schaffrath wrote: >>>> On 2007/08/17 , at 18:41, Joe Touch wrote: >>>>> AFAIK, congestion control response to in-band messages (ACKs) and >>>>> timeouts (implied loss, as TCP interprets it), as well as to >>>>> some new >>>>> fields (ECN, etc.) which are carried in the same packets. >>>>> >>>>> Reactions to external congestion signals - ICMP source quench >>>>> (which >>>>> has >>>>> been informally deprecated a while ago, but has not been >>>>> documented as >>>>> such yet) or otherwise - would constitute another opportunity >>>>> for a DOS >>>>> attack, and seem like a bad idea to encourage. >>>> >>>> I am note sure your security concerns really apply :) If the bad >>>> user >>>> controls the forwarding node, there is no need to rely on ICMP >>>> message >>>> to cause harm. Instead, just dropping random segments would do >>>> the job. >>>> If the bad user is off the forwarding node, she would need (as >>>> usual) >>>> guess port and sequence numbers. >>> >>> Only port numbers. Sequence numbers strictly don't matter for ICMPs. >> But that is under way, if I am not mistaken >> (draft-ietf-tcpm-icmp-attacks-02). And Linux for instance already >> implements it... > > I've already spoken about this at previous IETFs and on this list. Sorry. I am actually new to the matter... > The basic summary: > - the network is under no obligation to respond with ICMPs within > one RTT That's a very valuable hint! And gives motivation why RFC 1122 after the receipt of an ICMP (host/net) unreachable message only requests to flag a "soft error" to the application allows continuing sending (simply because the issue about the unreachability might have changed in the meantime...) Correct? Are there any other boundaries as RTT for ICMPs? Anyway, how come that there is the possibility of late ICMPs? > - as a result, checking to ensure that ICMPs are in-window is > incorrect > as it will drop legitimate responses - or worse, interpret them as > attacks > > The fact that an I-D remains on this point and that Linux > implements it > does not change the above. And how come that there is an I-D on dropping legitimate responses from the network? Maybe one mitigation might be to relax the window check to accept a few older windows and not just the current one, thereby allowing proper handling of "late" ICMPs, but still filtering some malicious ICMPs . But as this is so obvious is has probably some (hidden) shortcoming (which I can't think of at the moment). >>>> If she is able to guess right, she >>>> might as well opt to send forged ACK dupacks to cause harm, or >>>> for an >>>> ECN capable transport just one ECE marked ACK. >>> >>> ICMPs don't need to come from the endpoint IP address, i.e., address >>> verification will prevent spoofed ACKs, but cannot prevent ICMPs, >>> since >>> the latter need not have spoofed source addresses. >> >> Ok, but if a router is (potentially) able to check for spoofed IP >> source >> addresses it could as well check for spoofed/illegal ICMP payloads >> (which contain both IP addresses) . Isn't that true? > > Routers can check for spoofed addresses as they enter protected > regions > of the Internet; if there's a hole in that 'fence' however, packets > can > leak in. Once in, they can't necessarily be checked for spoofed > addresses unless they're authenticated, and most are not. But, again: isn't it true that if and only if for a given datagram a router is able to decide whether the source address of that datagram is spoofed, then that router could also decide (if that datagram contained an ICMP unreachable message) whether the source IP in the ICMP payload is spoofed or not (and act accordingly, i.e., drop it or not). So, overall there don't arise additional attack opportunities when there was some (to be defined) congestion control in face of ICMP (host/net) unreachable messages (which was my original claim). Sorry, maybe I am bit theoretical here, but I'd love to check if my understanding is correct. [...] Thanks again and thanks a lot!! Daniel Schaffrath _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 13 20:01:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVydA-0008GC-R6; Thu, 13 Sep 2007 20:01:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVydA-0008G3-Hg for tcpm@ietf.org; Thu, 13 Sep 2007 20:01:56 -0400 Received: from smtpoutm.mac.com ([17.148.16.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVyd9-0002az-69 for tcpm@ietf.org; Thu, 13 Sep 2007 20:01:56 -0400 Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpoutm.mac.com (Xserve/smtpout013/MantshX 4.0) with ESMTP id l8E01sTs008412; Thu, 13 Sep 2007 17:01:54 -0700 (PDT) Received: from [192.168.178.24] (p57a4bdfc.dip0.t-ipconnect.de [87.164.189.252]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id l8E01IE6024754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Sep 2007 17:01:51 -0700 (PDT) In-Reply-To: <46E8AB52.9060506@isi.edu> References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <20070817162542.GA2511@hut.isi.edu> <4AD719E5-AF65-4D4C-8BE8-B070793F69C3@mac.com> <20070907004335.GB48227@hut.isi.edu> <46E8AB52.9060506@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages Date: Fri, 14 Sep 2007 02:01:22 +0200 To: Joe Touch X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On 2007/09/13 , at 05:15, Joe Touch wrote: > Daniel Schaffrath wrote: >> On 2007/09/07 , at 02:43, Ted Faber wrote: >>> Acting in no official capacity, I say: >> Sorry, I don't get this. > > Ted is chair of the working group; he's taking that hat off in this > reply ;-) I see. I still don't get why he feels there is some need to reply "unofficially". Because of "Huh?"..? > ... >>> Assuming you believe these are valid messages, those codes >>> indicate that >>> the entity you want to talk to is not there or has gone away and >>> isn't >>> coming back. The sender is required to terminate the connection >>> because >>> the network has told it that the receiver cannot be reached and that >>> further packets will not be delivered. Sending any packets under >>> those >>> conditions will just take up space until they're dropped. >> >> I was actually joking about the term "congestion control". To me >> _congestion_ control is about how much to send and not whether to >> send >> at all. Of course, I understand that the latter is included in the >> former... in some way :) > > Congestion is "packets that slows down or drops other packets". > > Packets sent to unavailable ports may have nothing to do with > congestion > - they don't have to compete for resources. It's not about > relieving the > network from congestion - congestion control handles that. > > A good example: UDP has no congestion control, but can generate ICMP > responses. > > ... >>> Your text above sounds like you're saying that if a sender has >>> heard the >>> network say that there's a connectivity problem between the >>> sender and >>> receiver (ICMP destination unreachable) the sender is entitled to >>> react >>> less conservatively, even though all the evidence is that the >>> link is >>> congested. >> >> From my understanding the evidence is that just some link is (was) >> not >> working and that is not the same as a link is congested. Even, >> there is >> some slight indication that there is no congestion in the network >> (or at >> least the very part of it) as the ICMP message (as well as the >> segment >> eliciting the ICMP message) was not dropped and got to the TCP >> source. > > The ICMP travels on the reverse path; there could be congestion in the > forward path. There could be congestion only in that part of the path which the datagram eliciting the ICMP message has not yet travelled through, though. Up to that node where the ICMP message is generated there as no congestion as the eliciting datagram was not dropped. > ... >>> Explain to me why ICMP messages indicating that your packets are not >>> being delivered indicate you should not slow down. >> >> I am not saying you shouldn't slow down. After RTO of course you >> should >> reset cwnd and halve ssthresh. I was just thinking of skipping (or >> delaying) doubling RTO if the retransmission after RTO does not >> simply >> vanish in the network but is replied to with an ICMP (host/net) >> unreachable message. This seems reasonable to me if my above >> finding is >> true. > > Host/net unreachable means that you sent some packets along a path > that > couldn't reach that host/net. That's not to say that other packets > wouldn't be delivered properly. You mean other packet to be packets to another destination? Not other packet to the same destination (but from a different connection)? > It's like hitting a roadblock on the way across town. It doesn't > say the > endpoint is dead; that's why you don't give up, and also why you need > not change your congestion parameters. Finding a bad path could happen > by a routing transient - if you get these replies over a RTT, then > maybe > you give up. Or two RTTs. That's why 1122 doesn't say to ignore > these - > it says to use them as a hint. They're a hint that something can't be > reached - not that there's congestion. Yes. That is exactly my understanding. But as you (kindly) explain to me exactly my understanding I am really desperate what from my above writing could make you think that I have a different understanding. I am just talking about what to do if after a RTO exceeded the retransmission is replied to with an ICMP (host/net) unreachable message instead of no reply at all (indicating true congestion). (As I feel we have agreed upon) RFCs say to back-off exponentially in that case. Whereas I feel skipping further back-off might be non- contraproductive (BUT performance enhancing as it allow faster recovery!) as there is no evidence of congestion in the network (at least not for the very part of the path which is involved of the delivery of the ICMP unreachable message... if there is congestion in the rest of the path, it would be immediately discovered after the faster recovery). > ... >> Maybe my paragraph above was not clear. I am not saying that RFC 1122 >> suggests ICMP messages to have effect on cwnd. I am saying that >> from my >> understanding RFC 1122 allows a TCP to continue sending segments >> after >> having received an ICMP host/net unreachable message. > > Correct. > >> This seems to me >> as a waste of bandwidth as the arrival of the ICMP message just >> indicated that right now there is no route to the destination. >> Doesn't >> that sound reasonable? But maybe continuing sending makes sense >> together >> with some other RFC I am not aware of but someone else on the list. > > It's consistent within 1122. The message doesn't say there's > congestion; Yes! > it says routing doesn't work for the packet you sent. It may be a > waste > of bandwidth, but that's not the same as congestion - if you're > actually > competing for resources others need, your data packet would have been > dropped and you wouldn't get an ICMP at all. I really don't get this. With the same argument I could justify that a hacked/modified TCP (which for instance increases cwnd by two (instead of one) MSS for each ACK in slow-start) is just fine... Really, you don't want waste of bandwidth, do you? Of course, considering the hint you gave in the other email about late ICMP, it's no necessarily a waste, as in case of late ICMPs the issue might already have been resolved in the meantime. > Getting the ICMP > effectively says you are NOT experiencing congestion. > > Joe Thank you once again, Daniel _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 13 20:54:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVzRk-00025h-Rv; Thu, 13 Sep 2007 20:54:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVzRj-00025U-JO for tcpm@ietf.org; Thu, 13 Sep 2007 20:54:11 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVzRi-0001Hv-MY for tcpm@ietf.org; Thu, 13 Sep 2007 20:54:11 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l8E0rF4J015795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Sep 2007 17:53:15 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l8E0rFpL094767; Thu, 13 Sep 2007 17:53:15 -0700 (PDT) (envelope-from faber) Date: Thu, 13 Sep 2007 17:53:15 -0700 From: Ted Faber To: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages Message-ID: <20070914005315.GL13168@hut.isi.edu> References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <20070817162542.GA2511@hut.isi.edu> <4AD719E5-AF65-4D4C-8BE8-B070793F69C3@mac.com> <20070907004335.GB48227@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0919225112==" Errors-To: tcpm-bounces@ietf.org --===============0919225112== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UUBKWyapWpFAak7q" Content-Disposition: inline --UUBKWyapWpFAak7q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 12, 2007 at 08:23:32PM +0200, Daniel Schaffrath wrote: >=20 > On 2007/09/07 , at 02:43, Ted Faber wrote: >=20 > >Acting in no official capacity, I say: > Sorry, I don't get this. I'm one of the co-chairs of the TCPM working group. I'm just having a public conversation with you and neither you nor observers of this public conversation should take it as being an official position of this august WG. Because tempers fray and IETF participants are somewhat averse to people throwing their weight around, those of us who don't want to have those kinds of arguments try to be specific about when we're speaking ex cathedra. :-) > >If TCP has gotten to the point where a retransmission timer has =20 > >gone off > >not only has the transmission of the packet to be retransmitted =20 > >failed, > >but enough other packets have been lost that the fast retransmit > >algorithm (3 dupacks) has also not happened (yes, the window needs to > >have grown to 4...). In short, there's something very wrong with the > >communication between the endpoints, and drastic action is called for. > >Specifically, the sender acts as though the connection is almost new - > >window is as small as possible and the ssthresh is halved. > > > >Your text above sounds like you're saying that if a sender has =20 > >heard the > >network say that there's a connectivity problem between the sender and > >receiver (ICMP destination unreachable) the sender is entitled to =20 > >react > >less conservatively, even though all the evidence is that the link is > >congested. > From my understanding the evidence is that just some link is (was) =20 > not working and that is not the same as a link is congested. Even, =20 > there is some slight indication that there is no congestion in the =20 > network (or at least the very part of it) as the ICMP message (as =20 > well as the segment eliciting the ICMP message) was not dropped and =20 > got to the TCP source. So, the TCP stack really just knows that packets are not being acknowledged, and the current design interprets that as congestion. That's a conservative approach, and one people can and do argue about. If you'd like to argue about that interpretation of loss, the end-to-end mailing list might be a better place to do so. I mean we'll talk about it, too, but I think of it as a bigger picture issue. Still and all, one could say that the ICMPs count as extra evidence that a connection isn't congested but confused and should be treated differently. I'd recommend against treating them this way because: * ICMP operates on a different timescale than TCP. It may take a router longer to decide that there's a host unreachable situation than the TCP stack would. It may also take a router longer to detect the opposite. * They're really easy to spoof. I don't think you gain very much, either. If your application believes that the connection has stuttered - a route flap or something - the easiest way to fix it may be to reconnect. I'll bet you do this a couple times a day with your browser. Hitting reload on a slow loading page does exactly this. Other applications may value continuity of connection more. I think that kind of semantics - whether it's better for my application to retry or to stick it out on a slow connection - is known by the app and shouldn't be encoded in the transport. I realize that not going into exponential backoff is a pretty small case of a change in semantics, but it complicates things and it's not intuitive to me that it's worth the cost. > >Explain to me why ICMP messages indicating that your packets are not > >being delivered indicate you should not slow down. > > I am not saying you shouldn't slow down. After RTO of course you =20 > should reset cwnd and halve ssthresh. I was just thinking of skipping =20 > (or delaying) doubling RTO if the retransmission after RTO does not =20 > simply vanish in the network but is replied to with an ICMP (host/=20 > net) unreachable message. This seems reasonable to me if my above =20 > finding is true. I think its extra complexity for minimal gain. But, I haven't done anything to validate that opinion. Do you have some evidence either way? >=20 > >>Another thing is that RTO needs to expire to reach slow-start > >>recovery. If my understanding of RFC 1122 is correct, it's still > >>standard compliant to continue sending after having received the > >>first appropriate ICMP message. Maybe that's a bit too aggressive (as > >>opposed to slow-start recovery after an "ICMP induced" RTO). > > > >I believe your understanding of RFC 1122 is incorrect. I don't =20 > >believe > >that receiving an ICMP message of any kind has any effect on the TCP > >congestion control algorithms whatsoever (other than aborting the > >connection in the case above). ICMP messages are not part of a TCP > >connection, and receiving one does not count as receiveing a TCP > >packet, much less an ACK. After all, an ICMP message may well be =20 > >coming > >from an intermediate gateway. > Maybe my paragraph above was not clear. I am not saying that RFC 1122 =20 > suggests ICMP messages to have effect on cwnd. I am saying that from =20 > my understanding RFC 1122 allows a TCP to continue sending segments =20 > after having received an ICMP host/net unreachable message. This =20 > seems to me as a waste of bandwidth as the arrival of the ICMP =20 > message just indicated that right now there is no route to the =20 > destination. Doesn't that sound reasonable? But maybe continuing =20 > sending makes sense together with some other RFC I am not aware of =20 > but someone else on the list. I think I was unclear. There are several kinds of destination unreachable ICMP messages - subtypes of the message. RFCs 792 and 1122 list them. There are a set of them that indicate that any transport, including TCP, that get one have to shutdown the connection. If a host gets a destination unreachable message of the subtype "protocol unreachable" the host MUST abort the connection that caused it. That message indicates a long term error. If the destination unreachable message indicates an error that may not be so long term, the connection should continue to transmit, and if the transport decides to terminate the connection (e.g. a TCP timeout) it should report the ICMP error as well. That second choice is there because the subtypes in question could be caused by a single misrouted packet or something and are not strong evidence that the connection is impossible. Make sense? --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --UUBKWyapWpFAak7q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG6dt6aUz3f+Zf+XsRAi2QAJ9pZnnoh78+BhceJHUFbPn6/YzKjgCgx5Hm ewx9/MxSS+gw1dxK2HlTaZI= =gKfu -----END PGP SIGNATURE----- --UUBKWyapWpFAak7q-- --===============0919225112== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0919225112==-- From tcpm-bounces@ietf.org Fri Sep 14 02:31:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW4hX-00059Y-GL; Fri, 14 Sep 2007 02:30:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW4hW-00059S-0V for tcpm@ietf.org; Fri, 14 Sep 2007 02:30:50 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW4hV-0001tA-Al for tcpm@ietf.org; Fri, 14 Sep 2007 02:30:49 -0400 Received: from [127.0.0.1] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8E6UbLJ014141; Thu, 13 Sep 2007 23:30:38 -0700 (PDT) Message-ID: <46EA2A76.8040308@isi.edu> Date: Thu, 13 Sep 2007 23:30:14 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <46C5CFA1.3090603@isi.edu> <443EB15A-FBED-4325-AD04-CCC39E989DDE@mac.com> <46E15C78.4080706@isi.edu> <15CFCCD8-0CDD-4033-9B83-7C42AEEDD88A@mac.com> <46E8A7FE.6000404@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0552746677==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0552746677== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDF227513A51CE1095C6EC8FC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF227513A51CE1095C6EC8FC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniel Schaffrath wrote: =2E.. >> The basic summary: >> - the network is under no obligation to respond with ICMPs within one = RTT > That's a very valuable hint! And gives motivation why RFC 1122 after th= e > receipt of an ICMP (host/net) unreachable message only requests to flag= > a "soft error" to the application allows continuing sending (simply > because the issue about the unreachability might have changed in the > meantime...) Correct? Basically. It's an indication that a packet hit a roadblock, but not that the roadblock is essentially permanent. That happens only at the destination (i.e., if the destination is gone, then game's over). > Are there any other boundaries as RTT for ICMPs?=20 None per se. > Anyway, how come that > there is the possibility of late ICMPs? Routers respond with ICMPs only when they have cycles - otherwise, they could go into overload giving feedback. That's in RFC1812. >> - as a result, checking to ensure that ICMPs are in-window is incorrec= t >> as it will drop legitimate responses - or worse, interpret them as >> attacks >> >> The fact that an I-D remains on this point and that Linux implements i= t >> does not change the above. > And how come that there is an I-D on dropping legitimate responses from= > the network? >=20 > Maybe one mitigation might be to relax the window check to accept a few= > older windows and not just the current one, thereby allowing proper > handling of "late" ICMPs, but still filtering some malicious ICMPs . Bu= t > as this is so obvious is has probably some (hidden) shortcoming (which = I > can't think of at the moment). Once the window wraps all windows look the same. At that point, there's nothing useful to check. >>>>> If she is able to guess right, she >>>>> might as well opt to send forged ACK dupacks to cause harm, or for = an >>>>> ECN capable transport just one ECE marked ACK. >>>> >>>> ICMPs don't need to come from the endpoint IP address, i.e., address= >>>> verification will prevent spoofed ACKs, but cannot prevent ICMPs, si= nce >>>> the latter need not have spoofed source addresses. >>> >>> Ok, but if a router is (potentially) able to check for spoofed IP sou= rce >>> addresses it could as well check for spoofed/illegal ICMP payloads >>> (which contain both IP addresses) . Isn't that true? >> >> Routers can check for spoofed addresses as they enter protected region= s >> of the Internet; if there's a hole in that 'fence' however, packets ca= n >> leak in. Once in, they can't necessarily be checked for spoofed >> addresses unless they're authenticated, and most are not. > But, again: isn't it true that if and only if for a given datagram a > router is able to decide whether the source address of that datagram is= > spoofed, then that router could also decide (if that datagram contained= > an ICMP unreachable message) whether the source IP in the ICMP payload > is spoofed or not (and act accordingly, i.e., drop it or not). Not true. IP addresses are checked two ways - with explicit authentication (which we're not talking about; that involves IPsec, e.g.) or by verifying which port they arrive on (and which router they arrive from). Let's focus on that second part. Let's say that IP address X must come in on port 3 from router Q. ICMPs that report IP address X incorrect can come in on any port, from any router. There's no rule that ICMPs must be routed the same way as the IP packets they report on. The ICMP has a different source IP address, so it could easily be routed via other paths. > So, > overall there don't arise additional attack opportunities when there wa= s > some (to be defined) congestion control in face of ICMP (host/net) > unreachable messages (which was my original claim). I think there do, because of the above... Joe --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enigDF227513A51CE1095C6EC8FC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG6ip6E5f5cImnZrsRAi6IAKDj5k+O3b392AhSeVNKCszTc1ljNACgtMvZ n93CutBcZH2YcslFQ3LWsd0= =Qp/R -----END PGP SIGNATURE----- --------------enigDF227513A51CE1095C6EC8FC-- --===============0552746677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0552746677==-- From tcpm-bounces@ietf.org Fri Sep 14 02:45:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW4vh-00025R-HT; Fri, 14 Sep 2007 02:45:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW4vf-00025C-0o for tcpm@ietf.org; Fri, 14 Sep 2007 02:45:27 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW4ve-0002Hx-3E for tcpm@ietf.org; Fri, 14 Sep 2007 02:45:26 -0400 Received: from [127.0.0.1] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8E6imTI017361; Thu, 13 Sep 2007 23:44:49 -0700 (PDT) Message-ID: <46EA2DCD.4010109@isi.edu> Date: Thu, 13 Sep 2007 23:44:29 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <20070817162542.GA2511@hut.isi.edu> <4AD719E5-AF65-4D4C-8BE8-B070793F69C3@mac.com> <20070907004335.GB48227@hut.isi.edu> <46E8AB52.9060506@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0506876624==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0506876624== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA82D23A52117A4A2E9BEF422" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA82D23A52117A4A2E9BEF422 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Daniel, et al., Daniel Schaffrath wrote: >> ... >>>> Your text above sounds like you're saying that if a sender has heard= >>>> the >>>> network say that there's a connectivity problem between the sender a= nd >>>> receiver (ICMP destination unreachable) the sender is entitled to re= act >>>> less conservatively, even though all the evidence is that the link i= s >>>> congested. >>> >>> From my understanding the evidence is that just some link is (was) no= t >>> working and that is not the same as a link is congested. Even, there = is >>> some slight indication that there is no congestion in the network (or= at >>> least the very part of it) as the ICMP message (as well as the segmen= t >>> eliciting the ICMP message) was not dropped and got to the TCP source= =2E >> >> The ICMP travels on the reverse path; there could be congestion in the= >> forward path. > > There could be congestion only in that part of the path which the > datagram eliciting the ICMP message has not yet travelled through, > though. Correct, but that's not relevant. Getting an ICMP message tells you a single packet got to a certain point in the path; it doesn't say that other packets didn't get dropped. It's not an indication of "no congestion", as a result. > Up to that node where the ICMP message is generated there as no > congestion as the eliciting datagram was not dropped. "No congestion" for that packet. Unless you get an ICMP for every packet you sent, you can't assume that you have no congestion. However, since routers are supposed to not send ICMPs that frequently (see RFC1812), only a fraction of packets that arrive at a router would generate an ICMP reply (even if all 'should'). =2E.. >> Host/net unreachable means that you sent some packets along a path tha= t >> couldn't reach that host/net. That's not to say that other packets >> wouldn't be delivered properly. > > You mean other packet to be packets to another destination? Not other > packet to the same destination (but from a different connection)? Packets to the same destination from the same connection could go on a different path and be delivered properly. The Internet makes no guarantee that all packets travel the same path all the time, even within a single flow. >> It's like hitting a roadblock on the way across town. It doesn't say t= he >> endpoint is dead; that's why you don't give up, and also why you need >> not change your congestion parameters. Finding a bad path could happen= >> by a routing transient - if you get these replies over a RTT, then may= be >> you give up. Or two RTTs. That's why 1122 doesn't say to ignore these = - >> it says to use them as a hint. They're a hint that something can't be >> reached - not that there's congestion. > > Yes. That is exactly my understanding. But as you (kindly) explain to m= e > exactly my understanding I am really desperate what from my above > writing could make you think that I have a different understanding. I a= m > just talking about what to do if after a RTO exceeded the retransmissio= n > is replied to with an ICMP (host/net) unreachable message instead of no= > reply at all (indicating true congestion). An ICMP host/net unreachable doesn't indicate "no congestion", so there's no reason to act differently when you get an individual such message. If you get repeated such messages, the network is saying that it can't find a way around a roadblock - presuming, however, that the connection isn't making any progress. If it is, all you know is that some of the multiple paths are broken. None of this has anything to do with congstion, though. > (As I feel we have agreed > upon) RFCs say to back-off exponentially in that case. For true congestion. > Whereas I feel > skipping further back-off might be non-contraproductive (BUT > performance enhancing as it allow faster recovery!) as there is no > evidence of congestion in the network (at least not for the very part o= f > the path which is involved of the delivery of the ICMP unreachable > message... if there is congestion in the rest of the path, it would be > immediately discovered after the faster recovery). See above. >> ... >>> Maybe my paragraph above was not clear. I am not saying that RFC 1122= >>> suggests ICMP messages to have effect on cwnd. I am saying that from = my >>> understanding RFC 1122 allows a TCP to continue sending segments aft= er >>> having received an ICMP host/net unreachable message. >> >> Correct. >> >>> This seems to me >>> as a waste of bandwidth as the arrival of the ICMP message just >>> indicated that right now there is no route to the destination. Doesn'= t >>> that sound reasonable? But maybe continuing sending makes sense toget= her >>> with some other RFC I am not aware of but someone else on the list. >> >> It's consistent within 1122. The message doesn't say there's congestio= n; > Yes! It doesn't say there's no congestion either. It doesn't need to say one or the other! >> it says routing doesn't work for the packet you sent. It may be a wast= e >> of bandwidth, but that's not the same as congestion - if you're actual= ly >> competing for resources others need, your data packet would have been >> dropped and you wouldn't get an ICMP at all. > > I really don't get this. With the same argument I could justify that a > hacked/modified TCP (which for instance increases cwnd by two (instead > of one) MSS for each ACK in slow-start) is just fine... That's violating other principles of TCP. Why is that justified because of this? > Really, you don't want waste of bandwidth, do you? The Internet wastes bandwidth all the time. TCP probes waste bandwidth, e.g. What we want to reduce is bandwidth that is wasted that could be used for other connections - that's congestion. Sending packets when there *might* be a roadblock (which is what a single ICMP host/net unreachable means) isn't wasteful; it's needed for discovery of alternate paths. Joe --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enigA82D23A52117A4A2E9BEF422 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG6i3NE5f5cImnZrsRAiHMAJ9f8GvlZIZyKWTRX9pHWzcC6ewDWgCeL8yF qbNJDF5xgH1xMwdrSXxI1Lc= =34It -----END PGP SIGNATURE----- --------------enigA82D23A52117A4A2E9BEF422-- --===============0506876624== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0506876624==-- From tcpm-bounces@ietf.org Tue Sep 18 17:39:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXkl6-0007U9-3K; Tue, 18 Sep 2007 17:37:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXkl4-0007Rl-AS; Tue, 18 Sep 2007 17:37:26 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXkl3-0000jo-SX; Tue, 18 Sep 2007 17:37:26 -0400 X-IronPort-AV: E=Sophos;i="4.20,270,1186383600"; d="scan'208";a="220552824" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 18 Sep 2007 14:37:25 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8ILbOLK029749; Tue, 18 Sep 2007 14:37:24 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8ILbO0d029090; Tue, 18 Sep 2007 21:37:24 GMT From: "Dan Wing" To: "'tsvwg WG'" References: Subject: RE: [tcpm] consensus call: draft-larsen-tsvwg-port-randomization to WGitem Date: Tue, 18 Sep 2007 14:37:24 -0700 Message-ID: <02f001c7fa3c$1a485c00$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf1UxqO7yEuSj16Rwqj/d8GbbNKcwE6JJLA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2184; t=1190151445; x=1191015445; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[tcpm]=20consensus=20call=3A=20draft-larsen-tsvwg-por t-randomization=20to=20WGitem |Sender:=20; bh=L++wPkfS8tpafnjgTK0ZHxIHz43okq7Q5SRg6eq4xKU=; b=BqF7Y00ANx3iI/6C4EVL9dIkPQkHgwc4wVd+qFvDx4exCsPCxKX6GzCpB/Uj3oqPEU+Uc+Zn +hSvu3fSSsXfR4WDgjdKZzCCl48jqZUJMk3Yno/99g0dDk1IcgwskIuX; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tcpm@ietf.org, draft-larsen-tsvwg-port-randomization@tools.ietf.org, 'DCCP mailing list' X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I support this document becoming a TSVWG working group item. During its transition to such, I would like the authors to more clearly extend the document's applicability to non-TCP protocols with port numbers. Specifically, the document should include "UDP", "DCCP", and "SCTP" (as well as TCP) in its introduction (and perhaps also in its abstract) so that anyone developing or writing host requirements for those protocols will have a better chance of finding this specification when working on those protocols. -d > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: Wednesday, September 12, 2007 8:39 AM > To: tsvwg WG > Cc: tcpm@ietf.org; > draft-larsen-tsvwg-port-randomization@tools.ietf.org; DCCP > mailing list > Subject: [tcpm] consensus call: > draft-larsen-tsvwg-port-randomization to WGitem > > Hi, > > regarding http://tools.ietf.org/html/draft-larsen-tsvwg-port- > randomization, there was quite a bit of discussion around this draft > during the summer. My personal take is that I saw more positive than > negative comments, but I'd like to confirm this. > > I'd hence like to start a consensus call on whether we want to take > this document to be the basis for a standards-track work item in > TSVWG that will recommend a randomization scheme for operating > systems allocation of source ports. Because this scheme will cover > all our transport protocols, I'm CC'ing the DCCP and TCPM working > groups. This consensus call will run for two weeks, until > September 28. > > Please comment on the tsvwg@ietf.org list (reply-to set > accordingly), > even if you have already commented be on this draft in the past. > > To make it easy for your chairs, please start your email by choosing > ONE of the options below, followed by any detailed comments you'd > like to make: > > (1) TSVWG should take on this work item, with this > document as the > basis > (2) TSVWG should take on this work item, but NOT with this > document as the basis > (3) TSVWG should NOT take on this work item > (4) don't care > > Thanks, > Lars > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 20 08:50:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYLTB-0003j6-Bm; Thu, 20 Sep 2007 08:49:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYLT9-0003hi-W5; Thu, 20 Sep 2007 08:49:23 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYLT2-0003xB-Mn; Thu, 20 Sep 2007 08:49:23 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8KCn59h015663; Thu, 20 Sep 2007 15:49:09 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 15:48:57 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 15:48:56 +0300 Received: from [172.21.37.211] (esdhcp037211.research.nokia.com [172.21.37.211]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8KCmtR8016282; Thu, 20 Sep 2007 15:48:55 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <11F1DD2D-16B4-43B0-B81A-3A925E428021@nokia.com> From: Lars Eggert Date: Thu, 20 Sep 2007 15:48:46 +0300 To: tsvwg WG X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Sep 2007 12:48:56.0968 (UTC) FILETIME=[9BB12080:01C7FB84] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: tcpm@ietf.org, draft-larsen-tsvwg-port-randomization@tools.ietf.org, DCCP mailing list Subject: [tcpm] REMINDER: consensus call: draft-larsen-tsvwg-port-randomization to WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1835066479==" Errors-To: tcpm-bounces@ietf.org --===============1835066479== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17--615554185; protocol="application/pkcs7-signature" --Apple-Mail-17--615554185 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I've seen two (positive) comments so far. Please comment. On 2007-9-12, at 18:38, ext Lars Eggert wrote: > regarding http://tools.ietf.org/html/draft-larsen-tsvwg-port- > randomization, there was quite a bit of discussion around this > draft during the summer. My personal take is that I saw more > positive than negative comments, but I'd like to confirm this. > > I'd hence like to start a consensus call on whether we want to take > this document to be the basis for a standards-track work item in > TSVWG that will recommend a randomization scheme for operating > systems allocation of source ports. Because this scheme will cover > all our transport protocols, I'm CC'ing the DCCP and TCPM working > groups. This consensus call will run for two weeks, until September > 28. > > Please comment on the tsvwg@ietf.org list (reply-to set > accordingly), even if you have already commented be on this draft > in the past. > > To make it easy for your chairs, please start your email by > choosing ONE of the options below, followed by any detailed > comments you'd like to make: > > (1) TSVWG should take on this work item, with this document as > the basis > (2) TSVWG should take on this work item, but NOT with this > document as the basis > (3) TSVWG should NOT take on this work item > (4) don't care > > Thanks, > Lars --Apple-Mail-17--615554185 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA5MjAxMjQ4NDdaMCMGCSqGSIb3DQEJBDEWBBTDrcL5jybtrIBa JmQkVxwtQYvTXjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEADGr4TwXNn0YzJMofsRvGgOTkQqSgJ4mLzLbjIlfMI9O51nL1rr6g P31GEjxKnoBZZEHLs1D3tYt146MRnbObm39v2R9ogl3wonlHCTcxuHh+LujwkYJ7bym12H16pXdu 6S2nJ3+RzqLzzlR7tm52US5Dw+XLnVlG3o2zK3l4CFcHT2UakVREgPgrsUHWdeOlgSEdTX96tw1A aiEGlrGp6mcIJlK9YkYArMRP329PoDRKgOJ3TtrsaTqGjZeugVhd40opCk/bKqqyGx+HH6eqkMeP Q/g7wuvoUGAKcgYp4b+y/A4XLO9LTu9BlHC8vQIVCcw7J23+b4TRSnasQwfXdgAAAAAAAA== --Apple-Mail-17--615554185-- --===============1835066479== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1835066479==-- From tcpm-bounces@ietf.org Thu Sep 20 15:23:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYRbI-0004CJ-3v; Thu, 20 Sep 2007 15:22:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYRbG-0004BW-Ez for tcpm@ietf.org; Thu, 20 Sep 2007 15:22:10 -0400 Received: from smtpoutm.mac.com ([17.148.16.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYRbA-00086B-3t for tcpm@ietf.org; Thu, 20 Sep 2007 15:22:10 -0400 Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpoutm.mac.com (Xserve/smtpout012/MantshX 4.0) with ESMTP id l8KJLmPk004813; Thu, 20 Sep 2007 12:21:48 -0700 (PDT) Received: from [192.168.178.24] (p57a4bfe5.dip0.t-ipconnect.de [87.164.191.229]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id l8KJLehp028489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Sep 2007 12:21:43 -0700 (PDT) In-Reply-To: <20070914005315.GL13168@hut.isi.edu> References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <20070817162542.GA2511@hut.isi.edu> <4AD719E5-AF65-4D4C-8BE8-B070793F69C3@mac.com> <20070907004335.GB48227@hut.isi.edu> <20070914005315.GL13168@hut.isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <12EA28CC-C380-46EB-8886-C7BA9EC86148@mac.com> Content-Transfer-Encoding: 7bit From: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages Date: Thu, 20 Sep 2007 21:21:14 +0200 To: Ted Faber X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On 2007/09/14 , at 02:53, Ted Faber wrote: > On Wed, Sep 12, 2007 at 08:23:32PM +0200, Daniel Schaffrath wrote: >> On 2007/09/07 , at 02:43, Ted Faber wrote: [...] >>> If TCP has gotten to the point where a retransmission timer has >>> gone off >>> not only has the transmission of the packet to be retransmitted >>> failed, >>> but enough other packets have been lost that the fast retransmit >>> algorithm (3 dupacks) has also not happened (yes, the window >>> needs to >>> have grown to 4...). In short, there's something very wrong with >>> the >>> communication between the endpoints, and drastic action is called >>> for. >>> Specifically, the sender acts as though the connection is almost >>> new - >>> window is as small as possible and the ssthresh is halved. >>> >>> Your text above sounds like you're saying that if a sender has >>> heard the >>> network say that there's a connectivity problem between the >>> sender and >>> receiver (ICMP destination unreachable) the sender is entitled to >>> react >>> less conservatively, even though all the evidence is that the >>> link is >>> congested. >> From my understanding the evidence is that just some link is (was) >> not working and that is not the same as a link is congested. Even, >> there is some slight indication that there is no congestion in the >> network (or at least the very part of it) as the ICMP message (as >> well as the segment eliciting the ICMP message) was not dropped and >> got to the TCP source. > > So, the TCP stack really just knows that packets are not being > acknowledged, and the current design interprets that as congestion. > That's a conservative approach, and one people can and do argue about. > If you'd like to argue about that interpretation of loss, the end- > to-end > mailing list might be a better place to do so. I mean we'll talk > about > it, too, but I think of it as a bigger picture issue. I am subscribed to it. My impression is that the (active) audience is quite is same as on this list... and they all are "holistics" ;) > Still and all, one could say that the ICMPs count as extra evidence > that > a connection isn't congested but confused and should be treated > differently. I'd recommend against treating them this way because: > > * ICMP operates on a different timescale than TCP. It may take > a router longer to decide that there's a host unreachable > situation than the TCP stack would. It may also take a router > longer to detect the opposite. In my (naive?) understanding they not necessarily operate on a different timescale. For instance, it may take a router some time to execute an ARP request which may fail and then it would send a late ICMP (for the initial early segment, the later one got queued, then dropped). But if for whatever reason a port is disconnected (and by this a whole (sub-)net vanishes from the routing table) the router might be able to immediately (within an RTT) decide to send an ICMP. In either case the TCP source can decide about the timescale an arriving ICMP operates on (by looking at the sequence numbers therein). Of course, provided all involved nodes being non-malicious. > * They're really easy to spoof. I got that in the meantime from Jon explanation. And how come, if they are really that easy to spoof, that for ICMP port/proto/etc. unreachable messages RFC 1122 asks to drop the connection? Isn't that a very easy attack then. btw: I just noticed while browsing the Linux source that Linux treats port/proto/net/host unreachable messages all the same, i.e., flag an error on the socket and that's it. Anyways: if ICMP were used to skip doubling RTO an attacker cannot make a TCP source to flood the network by this. > I don't think you gain very much, either. If your application > believes > that the connection has stuttered - a route flap or something - the > easiest way to fix it may be to reconnect. I'll bet you do this a > couple times a day with your browser. Hitting reload on a slow > loading > page does exactly this. Other applications may value continuity of > connection more. I exhibit exactly this behavior. And I don't like it. I'd like the network to solve these issues for me... :) [...] >>> Explain to me why ICMP messages indicating that your packets are not >>> being delivered indicate you should not slow down. >> >> I am not saying you shouldn't slow down. After RTO of course you >> should reset cwnd and halve ssthresh. I was just thinking of skipping >> (or delaying) doubling RTO if the retransmission after RTO does not >> simply vanish in the network but is replied to with an ICMP (host/ >> net) unreachable message. This seems reasonable to me if my above >> finding is true. > > I think its extra complexity for minimal gain. > But, I haven't done anything to validate that opinion. Do you have > some > evidence either way? Complexity seems to be almost a dysphemism to me here. The gain is obviously a much faster restarting connection. And it's extraordinary... given an adequate scenario which is of course not the usual dial-up leafnode to the wired Internet but for instance a node which is part of a subnet managed by olsrd (causing route interruptions and the like). The question is if there is some rationale for this behavior. Actually, I was thinking there was (ICMP reply for single slow-start recovery retransmit indicating no congestion for the first few hops at least). But in the meantime I found that for zero window probing (which is comparable to "roadblock" probing) RFC 1122 in 4.2.2.17 recommends exponentiell back-off as well. Whereas I understand that exponentiell back-off is necessary for the _network_ to recover from severe congestion, I don't understand why exponentiell back-off is recommended for recovering from zero windows (which is more or less _application_ congestion). Of course, for zero window probes which are not ACKed back-off is essentiel. There is a DISCUSSION paragraph in 4.2.2.17 which is unfortunately not clear to me. It might be understood as if exponentiell back-off allows fast recovery from a zero window condition, although (from my understanding) it does exactly the opposite. Of course, it may all boil down to defining words, i.e., exponentiell back-off being fast by definition as complexity theory knows off much worse growth. But "traditionally" exponentiell is not fast. Maybe you have further pointers? Thank you, Daniel Schaffrath _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 20 18:42:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYUg5-0002U4-71; Thu, 20 Sep 2007 18:39:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYUg4-0002P5-CI for tcpm@ietf.org; Thu, 20 Sep 2007 18:39:20 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYUfv-0004G1-Uk for tcpm@ietf.org; Thu, 20 Sep 2007 18:39:17 -0400 Received: from [127.0.0.1] ([128.9.176.72]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8KMcdsA006381; Thu, 20 Sep 2007 15:38:39 -0700 (PDT) Message-ID: <46F2F65A.50303@isi.edu> Date: Thu, 20 Sep 2007 15:38:18 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <20070817162542.GA2511@hut.isi.edu> <4AD719E5-AF65-4D4C-8BE8-B070793F69C3@mac.com> <20070907004335.GB48227@hut.isi.edu> <20070914005315.GL13168@hut.isi.edu> <12EA28CC-C380-46EB-8886-C7BA9EC86148@mac.com> In-Reply-To: <12EA28CC-C380-46EB-8886-C7BA9EC86148@mac.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1489007984==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1489007984== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB45777EA4C68FD73A0DC8C42" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB45777EA4C68FD73A0DC8C42 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniel Schaffrath wrote: >=20 =2E.. >> * ICMP operates on a different timescale than TCP. It may take >> a router longer to decide that there's a host unreachable >> situation than the TCP stack would. It may also take a router >> longer to detect the opposite. > In my (naive?) understanding they not necessarily operate on a differen= t > timescale. For instance, it may take a router some time to execute an > ARP request which may fail and then it would send a late ICMP (for the > initial early segment, the later one got queued, then dropped). But if > for whatever reason a port is disconnected (and by this a whole > (sub-)net vanishes from the routing table) the router might be able to > immediately (within an RTT) decide to send an ICMP. In either case the > TCP source can decide about the timescale an arriving ICMP operates on > (by looking at the sequence numbers therein).=20 If the sequence numbers wrap, it can't tell much. Nothing guarantees that ICMPs are generated before such wrap occurs - even assuming benign behavior. =2E.. >> I don't think you gain very much, either. If your application believe= s >> that the connection has stuttered - a route flap or something - the >> easiest way to fix it may be to reconnect. I'll bet you do this a >> couple times a day with your browser. Hitting reload on a slow loadin= g >> page does exactly this. Other applications may value continuity of >> connection more. > I exhibit exactly this behavior. And I don't like it. I'd like the > network to solve these issues for me... :) A "best effort" network doesn't provide that service. You may want a circuit-oriented system. Joe --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enigB45777EA4C68FD73A0DC8C42 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG8vZaE5f5cImnZrsRAqEiAJ9UP1lh/n4ma75swa5lodCNCAMaQwCgii16 4kbvWoVVia60TBBtXKhKA+E= =nAjf -----END PGP SIGNATURE----- --------------enigB45777EA4C68FD73A0DC8C42-- --===============1489007984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1489007984==-- From tcpm-bounces@ietf.org Mon Sep 24 13:42:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrv6-00037l-Db; Mon, 24 Sep 2007 13:40:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrv5-00037X-7M for tcpm@ietf.org; Mon, 24 Sep 2007 13:40:31 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZrux-0007P8-6f for tcpm@ietf.org; Mon, 24 Sep 2007 13:40:31 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8OHe67Z020723 for ; Mon, 24 Sep 2007 10:40:07 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id EE4E2FD7D5A for ; Mon, 24 Sep 2007 13:39:59 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 61F7E2A7155 for ; Mon, 24 Sep 2007 13:38:56 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Mon, 24 Sep 2007 13:38:56 -0400 Message-Id: <20070924173856.61F7E2A7155@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Subject: [tcpm] 2581 implementation report X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0412109422==" Errors-To: tcpm-bounces@ietf.org --===============0412109422== Content-Type: multipart/signed; boundary="==_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --==_bOundary Content-Type: multipart/mixed; boundary="=_bOundary" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- Attached is a short implementation report to send to the IESG when the WG is ready to forward 2581bis for publication as a draft standard. Please take a look at it and let me know if you have anything to add and/or have heartburn with anything in the writeup. (I am just floating this by the WG for opinions. Clearly we need to do a WGLC on the document itself before anything is forwarded over to the IESG.) Thanks, allman --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Disposition: attachment; filename=impl-report.txt Background: + RFC 2581 is a re-write of RFC 2001. RFC 2001 was a description of TCP's congestion control algorithms that was published long after these algorithms were in nearly ubiquitous deployment throughout the Internet (largely triggered by the congestion collapses of the mid-1980s). + While RFC 2001 was a description of the algorithms, RFC 2581 is a more traditional specification. We stress that the RFC was written based on running code and experience. + The mechanisms in RFC 3042 (Limited Transmit) and RFC 3390 (Larger Initial Congestion Window) are also rolled into the current document. Both of these enhancements are Proposed Standards that have gathered wide consensus within the community based on deployment experience. + The traditional test of two interoperable implementations to move a Proposed Standard to Draft Standard is less obvious in the case of congestion control mechanisms. Congestion control is about *when* to send a segment and not *what* that segment looks like, how to process it, how big fields are, etc. Therefore, it is difficult to assess "interoperability" in the traditional sense. Below we cite several sources that show or suggest that multiple implementations of the mechanisms exist and seem to work as intended. + The new version of the document clarifies a number of small issues that implementers have asked about over the years, but does not make any large changes to the algorithms. Known Implementations: + [WS95] discusses the BSD implementation of the core algorithms in RFC 2581 (slow start, congestion avoidance, fast retransmit and fast recovery). This implementation has formed the basis of the TCP stack in numerous operating systems (NetBSD, FreeBSD, OpenBSD, SunOS 4.x, BSDI, etc.). While various operating systems may have diverged in small details (some of which is documented in RFC 2581) the basic algorithms do not seem to have changed. + [Pax97] analyzes a number of implementations, finding both correct and incorrect behavior relative to RFC 2581 across a variety of implementations. The incorrect behavior fed into [RFC2525]. + [MAF05] tests for conformance along a number of angles by probing the TCPs of over 70K web servers with specialized packet streams that induce the stack to show how it handles various situations. The results include: + The vast majority of server reduce their congestion window by half in response to congestion (per RFC 2581's congestion avoidance). + The majority of the web servers used an initial congestion window of 1--2 packets. + Limited Transmit was used in over 20% of the servers. + While some servers do not use fast retransmit the overwhelming majority implement it. + Many web servers use the fast recovery algorithm (with a number using more advanced recovery such as NewReno [RFC3782] or SACK-based loss recovery techniques [RFC2018,RFC3517]. (Note that [MAF05] updates some of the results of [PF01]. The newer results confirm the older results.) References: [MAF05] Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. ACM Computer Communication Review, 35(2), April 2005. [Pax97] Vern Paxson. Automated Packet Trace Analysis of TCP Implementations. ACM SIGCOMM, September 1997. [PF01] Jitu Padhye, Sally Floyd. Identifying the TCP Behavior of Web Servers, SIGCOMM 2001, August 2001. [WS95] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The Implementation", Addison-Wesley, 1995. --=_bOundary-- --==_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG9/YwWyrrWs4yIs4RAqCbAKCXHwhWSFXjmvjEIJIoIJfMR/jscQCeOjvE Zw65VXNdYbRqy3OuYzEyqnI= =GD2w -----END PGP SIGNATURE----- --==_bOundary-- --===============0412109422== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0412109422==-- From tcpm-bounces@ietf.org Mon Sep 24 13:46:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZs0L-00083E-5M; Mon, 24 Sep 2007 13:45:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZs0J-000830-FO for tcpm@ietf.org; Mon, 24 Sep 2007 13:45:55 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZs0I-0001EL-RQ for tcpm@ietf.org; Mon, 24 Sep 2007 13:45:55 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8OHjsGl020799 for ; Mon, 24 Sep 2007 10:45:54 -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 8428EFD7E6C for ; Mon, 24 Sep 2007 13:45:48 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id F2C662A7182 for ; Mon, 24 Sep 2007 13:44:44 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Mon, 24 Sep 2007 13:44:44 -0400 Message-Id: <20070924174444.F2C662A7182@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [tcpm] tcpsecure: how strong to recommend? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1579756908==" Errors-To: tcpm-bounces@ietf.org --===============1579756908== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- The seeming last issue with the tcpsecure document is how strong to recommend the various mitigations. To review, there are three mitigations for RST, SYN and data injection attacks. The question is whether to say that a TCP (1) MAY use all these mitigations, (2) SHOULD use all these mitigations or (3) SHOULD use the mitigations for the RST & SYN attacks and MAY use the data injection mitigation. Clearly there are other permutations (and one could also bring MUST and MUST NOT into the conversation), however these three options have been voiced. If you have some other permutation then voice it. In the meeting in Chicago we took a "visual hum" and the tally looks like this: all SHOULDs: 4 all MAYs: 3 two SHOULDs and a MAY: 8 So, our inclination is to go with option (3) from my list above. If you think this is the wrong way to go please yell---especially if you are not reflected in the 15 folks who took part in the visual hum. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG9/eMWyrrWs4yIs4RApP+AJ9shDI6GDSehWx1a4CnhUGJItKv3gCfRrGA s48icH/+zUennjJlTOqYv7E= =DkQ5 -----END PGP SIGNATURE----- --=_bOundary-- --===============1579756908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1579756908==-- From tcpm-bounces@ietf.org Mon Sep 24 17:39:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZvcP-0001rP-IQ; Mon, 24 Sep 2007 17:37:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZvcO-0001rA-K3 for tcpm@ietf.org; Mon, 24 Sep 2007 17:37:28 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZvcN-0006c0-69 for tcpm@ietf.org; Mon, 24 Sep 2007 17:37:28 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l8OLaRWe019517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Sep 2007 14:36:27 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l8OLaRb5040627; Mon, 24 Sep 2007 14:36:27 -0700 (PDT) (envelope-from faber) Date: Mon, 24 Sep 2007 14:36:27 -0700 From: Ted Faber To: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages Message-ID: <20070924213627.GE39402@hut.isi.edu> References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> <20070817162542.GA2511@hut.isi.edu> <4AD719E5-AF65-4D4C-8BE8-B070793F69C3@mac.com> <20070907004335.GB48227@hut.isi.edu> <20070914005315.GL13168@hut.isi.edu> <12EA28CC-C380-46EB-8886-C7BA9EC86148@mac.com> Mime-Version: 1.0 In-Reply-To: <12EA28CC-C380-46EB-8886-C7BA9EC86148@mac.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0958589867==" Errors-To: tcpm-bounces@ietf.org --===============0958589867== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ExXT7PjY8AI4Hyfa" Content-Disposition: inline --ExXT7PjY8AI4Hyfa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 20, 2007 at 09:21:14PM +0200, Daniel Schaffrath wrote: >=20 > On 2007/09/14 , at 02:53, Ted Faber wrote: > > * ICMP operates on a different timescale than TCP. It may take > > a router longer to decide that there's a host unreachable > > situation than the TCP stack would. It may also take a router > > longer to detect the opposite. > In my (naive?) understanding they not necessarily operate on a =20 > different timescale. For instance, it may take a router some time to =20 > execute an ARP request which may fail and then it would send a late =20 > ICMP (for the initial early segment, the later one got queued, then =20 > dropped). But if for whatever reason a port is disconnected (and by =20 > this a whole (sub-)net vanishes from the routing table) the router =20 > might be able to immediately (within an RTT) decide to send an ICMP. =20 > In either case the TCP source can decide about the timescale an =20 > arriving ICMP operates on (by looking at the sequence numbers =20 > therein). Of course, provided all involved nodes being non-malicious. Yeah, but that seems like a long run for a short slide to me, as a private individual. It might help in very simple cases, but there are a couple "might"s in there and a TCP endpoint making a decision about an ICMP packet based on matching sequence numbers. Practically this seems to be making TCP more brittle to deal with a pretty uncommon case. >=20 > > * They're really easy to spoof. > I got that in the meantime from Jon explanation. And how come, if =20 > they are really that easy to spoof, that for ICMP port/proto/etc. =20 > unreachable messages RFC 1122 asks to drop the connection? Isn't that =20 > a very easy attack then. btw: I just noticed while browsing the Linux =20 > source that Linux treats port/proto/net/host unreachable messages all =20 > the same, i.e., flag an error on the socket and that's it. Have you seen: ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tcpm-icmp-atta= cks-02.txt Fernando and this group are looking at these issues. Perhaps your ideas can be combined with that document? >=20 > Anyways: if ICMP were used to skip doubling RTO an attacker cannot =20 > make a TCP source to flood the network by this. I don't think any of that is an obvious mechanism to cause a DoS attack. >=20 > >I don't think you gain very much, either. If your application =20 > >believes > >that the connection has stuttered - a route flap or something - the > >easiest way to fix it may be to reconnect. I'll bet you do this a > >couple times a day with your browser. Hitting reload on a slow =20 > >loading > >page does exactly this. Other applications may value continuity of > >connection more. > I exhibit exactly this behavior. And I don't like it. I'd like the =20 > network to solve these issues for me... :) I do it, too. TCP serves a lot of applications that aren't people browsing the web. Why do you think TCP should handle this rather than Firefox (for example)? >=20 > [...] >=20 > >>>Explain to me why ICMP messages indicating that your packets are not > >>>being delivered indicate you should not slow down. > >> > >>I am not saying you shouldn't slow down. After RTO of course you > >>should reset cwnd and halve ssthresh. I was just thinking of skipping > >>(or delaying) doubling RTO if the retransmission after RTO does not > >>simply vanish in the network but is replied to with an ICMP (host/ > >>net) unreachable message. This seems reasonable to me if my above > >>finding is true. > > > >I think its extra complexity for minimal gain. > >But, I haven't done anything to validate that opinion. Do you have =20 > >some > >evidence either way? >=20 > Complexity seems to be almost a dysphemism to me here. Perhaps you think complexity is a dirtier word than I do. It's hard to understand how making TCP's retransmission depend partially on ICMP isn't making TCP more complex. I'm happy to use whatever term you prefer. > The gain is =20 > obviously a much faster restarting connection. And it's =20 > extraordinary... given an adequate scenario which is of course not =20 > the usual dial-up leafnode to the wired Internet but for instance a =20 > node which is part of a subnet managed by olsrd (causing route =20 > interruptions and the like). It seems like the case you're considering - a TCP connection that has a conncectivity breach that's noticed by ICMP and restored within a few RTTs - is pretty uncommon. Many application protocols (HTTP,FTP) are already prepared to deal with these kind of interruptions. Again, I don't see a compelling case for the benefits. Just speaking for myself. >=20 > The question is if there is some rationale for this behavior. =20 > Actually, I was thinking there was (ICMP reply for single slow-start =20 > recovery retransmit indicating no congestion for the first few hops =20 > at least). But in the meantime I found that for zero window probing =20 > (which is comparable to "roadblock" probing) RFC 1122 in 4.2.2.17 =20 > recommends exponentiell back-off as well. Whereas I understand that =20 > exponentiell back-off is necessary for the _network_ to recover from =20 > severe congestion, I don't understand why exponentiell back-off is =20 > recommended for recovering from zero windows (which is more or less =20 > _application_ congestion). Of course, for zero window probes which =20 > are not ACKed back-off is essentiel. There is a DISCUSSION paragraph =20 > in 4.2.2.17 which is unfortunately not clear to me. It might be =20 > understood as if exponentiell back-off allows fast recovery from a =20 > zero window condition, although (from my understanding) it does =20 > exactly the opposite. Of course, it may all boil down to defining =20 > words, i.e., exponentiell back-off being fast by definition as =20 > complexity theory knows off much worse growth. But "traditionally" =20 > exponentiell is not fast. 4.2.2.17 is dealing with the case that one end of the connection is advertising a 0 size window. In this case the other end knows that the connection still exists, but it isn't accepting data. That whole probing operation is to elicit a window update if one has been lost. In general, TCP is conservative with sending probes of any kind. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --ExXT7PjY8AI4Hyfa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG+C3baUz3f+Zf+XsRAoNPAKDRhxGXdao9stC+05BjMp45QHjVOACgvYGJ o786yKkLnDfQo3qfIALSpM8= =L60i -----END PGP SIGNATURE----- --ExXT7PjY8AI4Hyfa-- --===============0958589867== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0958589867==-- From tcpm-bounces@ietf.org Mon Sep 24 18:35:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwVy-0007KA-GZ; Mon, 24 Sep 2007 18:34:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwVx-0007Ic-BQ for tcpm@ietf.org; Mon, 24 Sep 2007 18:34:53 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZwVr-0007kj-2k for tcpm@ietf.org; Mon, 24 Sep 2007 18:34:53 -0400 Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8OMYOnP003653; Mon, 24 Sep 2007 15:34:24 -0700 (PDT) Message-ID: <46F83B6D.6000301@isi.edu> Date: Mon, 24 Sep 2007 15:34:21 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <20070924174444.F2C662A7182@lawyers.icir.org> In-Reply-To: <20070924174444.F2C662A7182@lawyers.icir.org> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0371529246==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0371529246== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig41D22701165CA956BFA4475A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig41D22701165CA956BFA4475A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd encourage others to weigh in on this. I'm uncomfortable with our making recommendations to change TCP's fundamental behavior as a SHOULD on the basis of a handful of representatives. Joe Mark Allman wrote: > =20 > Folks- >=20 > The seeming last issue with the tcpsecure document is how strong to > recommend the various mitigations. To review, there are three > mitigations for RST, SYN and data injection attacks. The question is > whether to say that a TCP (1) MAY use all these mitigations, (2) SHOULD= > use all these mitigations or (3) SHOULD use the mitigations for the RST= > & SYN attacks and MAY use the data injection mitigation. Clearly there= > are other permutations (and one could also bring MUST and MUST NOT into= > the conversation), however these three options have been voiced. If yo= u > have some other permutation then voice it. >=20 > In the meeting in Chicago we took a "visual hum" and the tally looks > like this: >=20 > all SHOULDs: 4 > all MAYs: 3 > two SHOULDs and a MAY: 8 >=20 > So, our inclination is to go with option (3) from my list above. If yo= u > think this is the wrong way to go please yell---especially if you are > not reflected in the 15 folks who took part in the visual hum. >=20 > Thanks, > allman >=20 >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --------------enig41D22701165CA956BFA4475A 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 iD8DBQFG+DttE5f5cImnZrsRArtmAJ9hinDWttRX8as9V3zLQmNfrdJEpwCfaFk+ 5z4xgm/q3g1F4aKpUT2DRxU= =/tW1 -----END PGP SIGNATURE----- --------------enig41D22701165CA956BFA4475A-- --===============0371529246== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0371529246==-- From tcpm-bounces@ietf.org Mon Sep 24 22:32:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia0Bk-0003fc-AT; Mon, 24 Sep 2007 22:30:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia0Bj-0003cv-AL for tcpm@ietf.org; Mon, 24 Sep 2007 22:30:15 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia0BX-0008E2-KF for tcpm@ietf.org; Mon, 24 Sep 2007 22:30:03 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 069025A7DCD; Mon, 24 Sep 2007 23:29:29 -0300 (ART) Received: from fgont.gont.com.ar (237-176-231-201.fibertel.com.ar [201.231.176.237]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l8P2TLfI029744; Mon, 24 Sep 2007 23:29:22 -0300 Message-Id: <200709250229.l8P2TLfI029744@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Sep 2007 23:29:10 -0300 To: mallman@icir.org, tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <20070924174444.F2C662A7182@lawyers.icir.org> References: <20070924174444.F2C662A7182@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 24 Sep 2007 23:29:28 -0300 (ART) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 02:44 p.m. 24/09/2007, Mark Allman wrote: >In the meeting in Chicago we took a "visual hum" and the tally looks >like this: > > all SHOULDs: 4 > all MAYs: 3 > two SHOULDs and a MAY: 8 > >So, our inclination is to go with option (3) from my list above. If you >think this is the wrong way to go please yell---especially if you are >not reflected in the 15 folks who took part in the visual hum. My inclination is for option (2) (all MAYs). FWIW, I did not attend the last IETF. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Sep 24 22:49:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia0TP-0001sp-7S; Mon, 24 Sep 2007 22:48:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia0TO-0001sY-LR for tcpm@ietf.org; Mon, 24 Sep 2007 22:48:30 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia0TI-0006SF-Di for tcpm@ietf.org; Mon, 24 Sep 2007 22:48:30 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8P2mJJH028544; Mon, 24 Sep 2007 19:48:19 -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 D67E7FDB14D; Mon, 24 Sep 2007 22:48:13 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1E6CA2A7A80; Mon, 24 Sep 2007 22:47:08 -0400 (EDT) To: Joe Touch From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <46F83B6D.6000301@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Mon, 24 Sep 2007 22:47:08 -0400 Message-Id: <20070925024708.1E6CA2A7A80@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1399114046==" Errors-To: tcpm-bounces@ietf.org --===============1399114046== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I'd encourage others to weigh in on this. I'm uncomfortable with our > making recommendations to change TCP's fundamental behavior as a SHOULD > on the basis of a handful of representatives. Joe, I hear you. Ted and I chatted today and are also a bit leery here. We'd very much love to hear from others with opinions. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG+HarWyrrWs4yIs4RAvGIAKCXrDQUyh0/4VZa7QYs14rOv22LoACgk9fr xoaK8DZvdj6xKQRPOaE10xk= =ElT1 -----END PGP SIGNATURE----- --=_bOundary-- --===============1399114046== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1399114046==-- From tcpm-bounces@ietf.org Tue Sep 25 02:02:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia3SM-0002Np-Sc; Tue, 25 Sep 2007 01:59:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia3SK-0002Kn-Qm for tcpm@ietf.org; Tue, 25 Sep 2007 01:59:36 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia3SK-0001LQ-9j for tcpm@ietf.org; Tue, 25 Sep 2007 01:59:36 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l8P5xERB002041; Tue, 25 Sep 2007 08:59:14 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l8P5xBtt002038; Tue, 25 Sep 2007 08:59:12 +0300 Date: Tue, 25 Sep 2007 08:59:11 +0300 (EEST) From: Pekka Savola To: Mark Allman Subject: Re: [tcpm] 2581 implementation report In-Reply-To: <20070924173856.61F7E2A7155@lawyers.icir.org> Message-ID: References: <20070924173856.61F7E2A7155@lawyers.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4386/Tue Sep 25 03:44:53 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi X-Spam-Score: -1.4 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Mon, 24 Sep 2007, Mark Allman wrote: > Attached is a short implementation report to send to the IESG when the > WG is ready to forward 2581bis for publication as a draft standard. > Please take a look at it and let me know if you have anything to add > and/or have heartburn with anything in the writeup. > > (I am just floating this by the WG for opinions. Clearly we need to do > a WGLC on the document itself before anything is forwarded over to the > IESG.) Have all the features of the spec been implemented by at least two independent implementations? I don't see the writeup clearly answering that question. Half-aside: At different times, different folks have had varying views on what "all the features" mean -- whether it means every 'may/should/must' (lower or uppercase) or something larger, at the very least some more detail than "fast retransmit -- check!" would likely be helpful. Also, as most testing and observation references point to the work that was done prior to 2581 revision, you might want to add an explicit statement about how these changes should or shouldn't matter from the interoperability and implementation (i.e.: have the new modifications been implemented as well?) perspective. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 02:07:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia3Zs-0006NW-Lt; Tue, 25 Sep 2007 02:07:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia3Zr-0006NO-6k for tcpm@ietf.org; Tue, 25 Sep 2007 02:07:23 -0400 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia3Zq-0003mm-0S for tcpm@ietf.org; Tue, 25 Sep 2007 02:07:23 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l8P676qS002269; Tue, 25 Sep 2007 09:07:07 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l8P675q2002265; Tue, 25 Sep 2007 09:07:06 +0300 Date: Tue, 25 Sep 2007 09:07:05 +0300 (EEST) From: Pekka Savola To: Fernando Gont Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <200709250229.l8P2TLfI029744@venus.xmundo.net> Message-ID: References: <20070924174444.F2C662A7182@lawyers.icir.org> <200709250229.l8P2TLfI029744@venus.xmundo.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4386/Tue Sep 25 03:44:53 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Mon, 24 Sep 2007, Fernando Gont wrote: > At 02:44 p.m. 24/09/2007, Mark Allman wrote: >> In the meeting in Chicago we took a "visual hum" and the tally looks >> like this: >> >> all SHOULDs: 4 >> all MAYs: 3 >> two SHOULDs and a MAY: 8 >> >> So, our inclination is to go with option (3) from my list above. If you >> think this is the wrong way to go please yell---especially if you are >> not reflected in the 15 folks who took part in the visual hum. > > My inclination is for option (2) (all MAYs). > > FWIW, I did not attend the last IETF. Likewise. As a note, I do not see this as a comment on the technology or the modifications. What I don't like is the concept that new TCP standards track documents would define what all TCP implementations implement. Instead they should just define how to implement a particular modification if a vendor chooses to do so. If we need to mandate what vendors must implement in order to claim compliance with 'TCP', we need to update RFC 1122 or write a normative version of the TCP roadmap document. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 08:03:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia97Q-0004bU-BH; Tue, 25 Sep 2007 08:02:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia97O-0004Ok-Uu for tcpm@ietf.org; Tue, 25 Sep 2007 08:02:22 -0400 Received: from harrier.viasat.com ([12.198.241.131] helo=VGAEXCH02.hq.corp.viasat.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia97D-0003Jy-NK for tcpm@ietf.org; Tue, 25 Sep 2007 08:02:17 -0400 Received: from VGAEXCH01.hq.corp.viasat.com ([172.31.1.20]) by VGAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 08:02:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Tue, 25 Sep 2007 08:02:14 -0400 Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B065426EC2@VGAEXCH01.hq.corp.viasat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: Acf++62fVs7XjLaqTyaTX6n/3LHiXwAbe4z0 References: <20070924174444.F2C662A7182@lawyers.icir.org> <46F83B6D.6000301@isi.edu> From: "Agarwal, Anil" To: "Joe Touch" , X-OriginalArrivalTime: 25 Sep 2007 12:02:14.0738 (UTC) FILETIME=[E97F8320:01C7FF6B] X-Spam-Score: 1.8 (+) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1426883102==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============1426883102== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FF6B.E96389AF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FF6B.E96389AF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mark, Joe et al, =20 My inclination is to suggest - "all SHOULDs" =20 A second choice would be - "two SHOULDs and a MAY" =20 As far as I can see, the proposed mechanisms bring value to users and to = the Internet at large,=20 are relatively simple and backward compatible and do not (seem to) break = anything.=20 I would be hesitant leaving them as "MAY"; vendors should be strongly = encouraged=20 to implement security mechanisms. =20 Regards, Anil =20 Anil Agarwal ViaSat Inc. Germantown, MD ________________________________ From: Joe Touch [mailto:touch@ISI.EDU] Sent: Mon 9/24/2007 6:34 PM To: mallman@icir.org Cc: tcpm@ietf.org Subject: Re: [tcpm] tcpsecure: how strong to recommend? I'd encourage others to weigh in on this. I'm uncomfortable with our making recommendations to change TCP's fundamental behavior as a SHOULD on the basis of a handful of representatives. Joe Mark Allman wrote: >=20 > Folks- > > The seeming last issue with the tcpsecure document is how strong to > recommend the various mitigations. To review, there are three > mitigations for RST, SYN and data injection attacks. The question is > whether to say that a TCP (1) MAY use all these mitigations, (2) = SHOULD > use all these mitigations or (3) SHOULD use the mitigations for the = RST > & SYN attacks and MAY use the data injection mitigation. Clearly = there > are other permutations (and one could also bring MUST and MUST NOT = into > the conversation), however these three options have been voiced. If = you > have some other permutation then voice it. > > In the meeting in Chicago we took a "visual hum" and the tally looks > like this: > > all SHOULDs: 4 > all MAYs: 3 > two SHOULDs and a MAY: 8 > > So, our inclination is to go with option (3) from my list above. If = you > think this is the wrong way to go please yell---especially if you are > not reflected in the 15 folks who took part in the visual hum. > > Thanks, > allman > > > > > > = ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm ------_=_NextPart_001_01C7FF6B.E96389AF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [tcpm] tcpsecure: how strong to = recommend?=0A= =0A= =0A= =0A=
=0A=
Mark, Joe et = al,
=0A=
 
=0A=
My inclination is to suggest = -
=0A=
   "all = SHOULDs"
=0A=
 
=0A=
A second choice would be = -
    "two SHOULDs and a MAY"
=0A=
 
=0A=
As far as I can see, the = proposed mechanisms bring value to users and to the Internet at large, =
=0A=
are relatively simple and = backward compatible and do not (seem to) break anything.
=0A=
I would be hesitant leaving = them as "MAY"; vendors should be strongly encouraged
=0A=
to implement security = mechanisms.
=0A=
 
=0A=
Regards,
=0A=
Anil
=0A=
 
=0A=
Anil Agarwal
=0A=
ViaSat Inc.
=0A=
Germantown, MD
=0A=

=0A=
=0A= From: Joe Touch = [mailto:touch@ISI.EDU]
Sent: Mon 9/24/2007 6:34 = PM
To: mallman@icir.org
Cc: = tcpm@ietf.org
Subject: Re: [tcpm] tcpsecure: how strong to = recommend?

=0A=
=0A=

I'd encourage others to weigh in on this. I'm = uncomfortable with our
making recommendations to change TCP's = fundamental behavior as a SHOULD
on the basis of a handful of = representatives.

Joe

Mark Allman = wrote:
> 
> Folks-
>
> The seeming last = issue with the tcpsecure document is how strong to
> recommend the = various mitigations.  To review, there are three
> = mitigations for RST, SYN and data injection attacks.  The question = is
> whether to say that a TCP (1) MAY use all these mitigations, = (2) SHOULD
> use all these mitigations or (3) SHOULD use the = mitigations for the RST
> & SYN attacks and MAY use the data = injection mitigation.  Clearly there
> are other permutations = (and one could also bring MUST and MUST NOT into
> the = conversation), however these three options have been voiced.  If = you
> have some other permutation then voice it.
>
> = In the meeting in Chicago we took a "visual hum" and the tally = looks
> like = this:
>
>       all SHOULDs: = 4
>       all MAYs: = 3
>       two SHOULDs and a MAY: = 8
>
> So, our inclination is to go with option (3) from my = list above.  If you
> think this is the wrong way to go = please yell---especially if you are
> not reflected in the 15 = folks who took part in the visual hum.
>
> Thanks,
> = allman
>
>
>
>
>
> = ------------------------------------------------------------------------<= BR>>
> _______________________________________________
> = tcpm mailing list
> tcpm@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/tcpm

------_=_NextPart_001_01C7FF6B.E96389AF-- --===============1426883102== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1426883102==-- From tcpm-bounces@ietf.org Tue Sep 25 08:32:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9ZM-0005DI-O3; Tue, 25 Sep 2007 08:31:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9ZL-00057H-2u for tcpm@ietf.org; Tue, 25 Sep 2007 08:31:15 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia9ZG-0006ZS-OF for tcpm@ietf.org; Tue, 25 Sep 2007 08:31:10 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id A8685C328 for ; Tue, 25 Sep 2007 08:31:09 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l8PCV8P9003394; Tue, 25 Sep 2007 08:31:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l8PCV7On015451; Tue, 25 Sep 2007 08:31:07 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id AOTZDoKIJOE1; Tue, 25 Sep 2007 08:31:07 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l8PCV4j3015291;Tue, 25 Sep 2007 08:31:04 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 739F24FEB6; Tue, 25 Sep 2007 08:25:57 -0400 (EDT) Date: Tue, 25 Sep 2007 08:25:57 -0400 From: Wesley Eddy To: Fernando Gont Subject: Re: [tcpm] tcpsecure: how strong to recommend? Message-ID: <20070925122557.GA13675@grc.nasa.gov> References: <20070924174444.F2C662A7182@lawyers.icir.org> <200709250229.l8P2TLfI029744@venus.xmundo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709250229.l8P2TLfI029744@venus.xmundo.net> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Mon, Sep 24, 2007 at 11:29:10PM -0300, Fernando Gont wrote: > At 02:44 p.m. 24/09/2007, Mark Allman wrote: > > >In the meeting in Chicago we took a "visual hum" and the tally looks > >like this: > > > > all SHOULDs: 4 > > all MAYs: 3 > > two SHOULDs and a MAY: 8 > > > >So, our inclination is to go with option (3) from my list above. If you > >think this is the wrong way to go please yell---especially if you are > >not reflected in the 15 folks who took part in the visual hum. > > My inclination is for option (2) (all MAYs). > > FWIW, I did not attend the last IETF. I was at the meeting, and I think my hand is included in the "all MAYs" above. My personal opinion was that regardless of licensing terms, I think having known IPR on something that we recommend all TCP hosts to do is distasteful. Since the tcpsecure solution isn't generally useful, but only needed for specific cases, and the antispoof document described alternatives, I don't feel that the benefits of SHOULD outweigh the downside, so I'll say "all MAYs" again. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 08:55:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9wo-0000IW-Ji; Tue, 25 Sep 2007 08:55:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9wm-0000Ge-W7 for tcpm@ietf.org; Tue, 25 Sep 2007 08:55:28 -0400 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia9wg-0004Yu-Mj for tcpm@ietf.org; Tue, 25 Sep 2007 08:55:28 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l8PCsxls026301; Tue, 25 Sep 2007 05:54:59 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 05:54:59 -0700 Received: from [192.168.117.73] ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 05:54:58 -0700 In-Reply-To: References: <20070924174444.F2C662A7182@lawyers.icir.org> <200709250229.l8P2TLfI029744@venus.xmundo.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <299A2E1C-3704-4F76-B8A3-A3A2C98BA28E@windriver.com> Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] tcpsecure: how strong to recommend? Date: Tue, 25 Sep 2007 07:54:56 -0500 To: Pekka Savola X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Sep 2007 12:54:59.0058 (UTC) FILETIME=[47946D20:01C7FF73] X-Spam-Score: -1.0 (-) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tcpm@ietf.org, Fernando Gont , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I voted (3) at the meeting. My vote is with the understanding that the whole tcpsecure document is *not* becoming part of the base TCP specification, but is an optional addition that implementors may choose whether or not to implement. If they do choose to implement it, then within that context my vote is for two SHOULDs and a MAY. If my understanding is incorrect, and we are voting on SHOULD/MAY for making these part of the base TCP specification, then I would change my vote to (2) all MAYs. -David Borman On Sep 25, 2007, at 1:07 AM, Pekka Savola wrote: > On Mon, 24 Sep 2007, Fernando Gont wrote: >> At 02:44 p.m. 24/09/2007, Mark Allman wrote: >>> In the meeting in Chicago we took a "visual hum" and the tally looks >>> like this: >>> >>> all SHOULDs: 4 >>> all MAYs: 3 >>> two SHOULDs and a MAY: 8 >>> So, our inclination is to go with option (3) from my list above. >>> If you >>> think this is the wrong way to go please yell---especially if you >>> are >>> not reflected in the 15 folks who took part in the visual hum. >> >> My inclination is for option (2) (all MAYs). >> >> FWIW, I did not attend the last IETF. > > Likewise. > > As a note, I do not see this as a comment on the technology or the > modifications. What I don't like is the concept that new TCP > standards track documents would define what all TCP implementations > implement. Instead they should just define how to implement a > particular modification if a vendor chooses to do so. If we need > to mandate what vendors must implement in order to claim compliance > with 'TCP', we need to update RFC 1122 or write a normative version > of the TCP roadmap document. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 09:52:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaAoO-0000Es-Vb; Tue, 25 Sep 2007 09:50:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaAoN-0000Em-SS for tcpm@ietf.org; Tue, 25 Sep 2007 09:50:51 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaAoM-00005x-Pu for tcpm@ietf.org; Tue, 25 Sep 2007 09:50:51 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8PDoeSC017570; Tue, 25 Sep 2007 16:50:48 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 16:50:40 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 16:50:15 +0300 Received: from [172.21.35.42] ([172.21.35.42]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 16:50:14 +0300 In-Reply-To: <200709111615.SAA24923@TR-Sys.de> References: <200709111615.SAA24923@TR-Sys.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Pasi Sarolahti Date: Tue, 25 Sep 2007 16:49:26 +0300 To: =?ISO-8859-1?Q?ext_Alfred_H=CEnes?= X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Sep 2007 13:50:14.0591 (UTC) FILETIME=[FFCA9CF0:01C7FF7A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: tcpm@ietf.org Subject: [tcpm] Re: draft-ietf-tcpm-rfc4138bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi Alfred and all, Note to the list: we have got some off-list feedback regarding the F-=20 RTO draft and the companion evaluation document presented in Chicago, =20= available at: http://tools.ietf.org/html/draft-ietf-tcpm-rfc4138bis-00 http://tools.ietf.org/html/draft-kojo-tcpm-frto-eval-00 In attempt to spin up some discussion on the mailing list, with his =20 permission, I'm cc:ing my reply to Alfred to TCPM. To summarize the discussion below, the only open technical question =20 we have is whether to include the SACK variant of F-RTO from RFC 4138 =20= in the Proposed Standard, or whether to leave it out. The latter was =20 our choice for -00 version. We'd like to hear people's opinions on =20 this, or anything else regarding the above two drafts. We don't have =20 many to-do items on our list, so unless there are any comments/issues =20= coming up, I believe the next version of rfc4138bis should be quite =20 close to final on our behalf. More comments below... On Sep 11, 2007, at 19:15, ext Alfred H=CEnes wrote: >>> I have no technical objections to the draft, including the >>> streamlining performed, leaving out SCTP and SACK related topics. >> >> Thanks, good to know. There have been some opinions also for leaving >> the SACK version in the draft, so this kind of feedback are useful >> to see if there seems to be "rough consensus" on one way or another. >> Personally I would be happy to leave the SACK version out. > > Hmmmm. > > F-RTO for SCTP should definitely be left out now, and be dealt > with in a separate document if it turns out to be required. > (Furthermore, doing so avoids any possible conflicts regarding > which WG should deal with the documents, TCPM vs. TSVWG. :-) ) Thanks for the input. I think we agree. > Since I do not have detailed knowledge regarding the degree of > SACK support and actual use in the internet now, I admittedly > just had followed your arguments. > > But, if it turns ot that SACK will gain, or already has gained, > significant importance, it might indeed be reasonable to keep > the SACK variant of F-RTO in 4138bis. To this end, it might be > useful to consider and evaluate the role of SACK for the evolution > of other aspects of TCP (and other transport protocols); if it > turns out, e.g., that SACK would be quite useful and important > for the expected predominant response algoritms for F-RTO anyway, > that should be taken as a firm indication that the SACK variant > of F-RTO should be left in the document. First, one note of clarification: a TCP that uses SACK can still use =20 the basic version of F-RTO based on cumulative acknowledgements just =20 fine. The SACK variant of F-RTO was intended to improve cases where =20 duplicate ACKs (for reordering, for example) prevent detection of =20 spurious RTO with the basic algorithm. To my understanding such cases =20= are quite rare, so the additional benefit might not be too significant. I have started to hesitate with my opinion on the SACK variant. We =20 proposed dropping out the SACK variant from the 4138bis draft, =20 because it seemed that it has not been as thoroughly analyzed as the =20 basic F-RTO. Also, the SACK version of F-RTO has not been included in =20= all implementations that have the basic version (for example Linux =20 distribution has had only the basic version). However, after I =20 mentioned about dropping SACK in the Chicago presentation, it turned =20 out in the hallway discussions that there are implementations of the =20 SACK variant in real use. So if it seems that the consensus is for =20 keeping the SACK variant in 4138bis, that's fine with me as well. I'd =20= be happy to hear more comments on this! > For instance: > The RFCs produced by the PILC WG have presented the analysis of, > and recommendations for, the use of TCP in particular environments > with particular properties and/or restrictions. These RFCs should > be reconsidered (I do not have the time now to do that - even by > just scratching at the surface) to find out whether there are > important scenarios that might be particular candidates for gaining > high benefit from F-RTO (plus a matching response algorithm) which > already have requirements or recommendations for the use of SACK. Hmmm... Sorry, I'm not sure if I understood what you mean here. PILC =20 documents recommend SACK for the lossy links, but I don't see clear =20 relationship to F-RTO. Some of the documents discuss a bit about =20 spurious timeouts, but SACK is not mentioned in that scope. >>> Yet, overall IMHO the arguments in favor of F-RTO are now repeated >>> too often in the text - in sections 1. Introduction, 2.2 Discussion, >>> and 4. Evaluation ... >> >> Ok, I'll try to read these sections with this in mind. It might show >> from the text that in the first round for the Experimental RFC we >> needed to more work justifying F-RTO, which probably is not needed >> so much anymore. > > After my second pass over the evaluation draft, I also have > reconsidered that topic as well. > > Is it intended to have the latter be published as a companion, > Informational RFC, to the 4138bis, or shall it just serve WG > internal purposes (and IESG/IAB requirements -- not precisely > constrained in BCP 133 with regard to the form of publication)? > In particular in the former case, IMHO there should be a clear split > between the specification document (4138bis) and the eval document, > leaving *most* of the background and justification information and > evaluation report material out from the specs and replacing it by > pointers to the eval document, as far as BCP 133 admits. I'm not sure about the fate of the frto-eval draft. It's purpose was =20 to document the gained experience since the Experimental RFC 4138, to =20= support the process of advancing the document to Proposed Standard. =20 It could have been published in some different format (technical =20 report, etc.), but we thought that an Internet-Draft would be quite =20 IETF'ish. I think rfc4138bis should be readable on its own, without =20 references to the eval document. Thanks for the comments! - Pasi > Kind regards, > Alfred. > > > P.S.: Since I'm not on the TCPM (and TSVWG) lists, I thoughtlessly > have hereby written another personal communication that might > indeed be of interest for the group(s). Thus, if it deems useful > to you, please forward this message, or parts of it, to the list. > > --=20 > > +------------------------=20 > +--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-=20 > Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: =20 > -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-=20 > Sys.de | > +------------------------=20 > +--------------------------------------------+ > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 09:55:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaAs7-0002Pk-EX; Tue, 25 Sep 2007 09:54:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaAs5-0002Oi-Ja for tcpm@ietf.org; Tue, 25 Sep 2007 09:54:41 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaAs4-0000At-U2 for tcpm@ietf.org; Tue, 25 Sep 2007 09:54:41 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8PDsACV020054; Tue, 25 Sep 2007 16:54:33 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 16:54:26 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 16:54:25 +0300 Received: from [172.21.36.228] (esdhcp036228.research.nokia.com [172.21.36.228]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8PDsOjv003693; Tue, 25 Sep 2007 16:54:24 +0300 In-Reply-To: <46F83B6D.6000301@isi.edu> References: <20070924174444.F2C662A7182@lawyers.icir.org> <46F83B6D.6000301@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <44F9F627-9A49-4A63-9F38-0006F1FE2BDF@nokia.com> From: Lars Eggert Subject: Re: [tcpm] tcpsecure: how strong to recommend? Date: Tue, 25 Sep 2007 16:54:11 +0300 To: ext Joe Touch X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Sep 2007 13:54:25.0442 (UTC) FILETIME=[954F7020:01C7FF7B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0123920771==" Errors-To: tcpm-bounces@ietf.org --===============0123920771== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-39--179629542; protocol="application/pkcs7-signature" --Apple-Mail-39--179629542 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On 2007-9-25, at 1:34, ext Joe Touch wrote: > I'd encourage others to weigh in on this. I'm uncomfortable with our > making recommendations to change TCP's fundamental behavior as a > SHOULD > on the basis of a handful of representatives. this brings up an important point we need to clarify. The tcpsecure document contains a technical specification for multiple TCP mechanisms to protect against certain attacks. However, RFC 2026 recommends that technical specifications should also come with a statement of applicability, i.e., something that says when the technical specification should or should not be used. Many documents don't have this, and often that isn't an issue. The tcpsecure document is missing this piece, too, but in this case I believe this is causing some confusion. For some folks, this lack of a clear applicability statement means that the tcpsecure mechanisms become part of the "must-implement" set of TCP. To other folks, the MUST/SHOULD/MAY in the current document *are* a kind of applicability statement. I think it would be helpful if we would tease apart applicability statement and technical specification. What were missing is consensus on the applicability of the proposed set of mechanisms. During the discussion around this document, I've heard basically two choices being expressed: (1) all TCP stacks should implement tcpsecure (2) only TCP stacks that expect to support a significant number of connections for which the described attacks are possible should implement tcpsecure This is important to scope the discussion we're currently having on SHOULD vs. MAY. If the applicability is (1), a SHOULD with its should-have-a-really- good-reason-to-ignore semantics is a pretty strong statement that affects all stacks. Whereas if the applicability is (2) or something else that is more restricted than (1), a SHOULD is essentially without effect for stacks that don't consider themselves to fall under the conditions stated. Lars PS: Here is the relevant section from RFC2026: 3.1 Technical Specification (TS) A Technical Specification is any description of a protocol, service, procedure, convention, or format. It may completely describe all of the relevant aspects of its subject, or it may leave one or more parameters or options unspecified. A TS may be completely self- contained, or it may incorporate material from other specifications by reference to other documents (which might or might not be Internet Standards). A TS shall include a statement of its scope and the general intent for its use (domain of applicability). Thus, a TS that is inherently specific to a particular context shall contain a statement to that effect. However, a TS does not specify requirements for its use within the Internet; these requirements, which depend on the particular context in which the TS is incorporated by different system configurations, are defined by an Applicability Statement. --Apple-Mail-39--179629542 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA5MjUxMzU0MTFaMCMGCSqGSIb3DQEJBDEWBBSIp2K7qBAN/TkU UQNNaWv81RNfnTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAG/CLCkkIcmc/dqhF+2bk2J2MyyIuFBiRWLe2plTh34lhhqNZpJXd kkaoa+Uj57roJ+U9qRi/gxyQ/68OkX9pKTkJykHrvM36Xv30mSszaRwI0CtxRaZ9BosxWB3nZYGV 2UuY6rVIAP4YslVN3+8WRWlQ19Z3u15YilAEJgZ+mw2HVCePvro46Ofr9febk1OgQZLjEYu0kQFV ki/flVE8MVvQ4m5aLE4L2Yhrh3qXXwjfFkVla+1ZTCr0vVJGRmox5bRiVazZ/p0DDbOlyBeWWWTC VQ2uq/4DdGXdjABq0PlO34cOLW5J8leYBIvpOBKNseG6Y21CaVZUmDsmbSkpTAAAAAAAAA== --Apple-Mail-39--179629542-- --===============0123920771== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0123920771==-- From tcpm-bounces@ietf.org Tue Sep 25 10:04:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaB11-0003lg-BG; Tue, 25 Sep 2007 10:03:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaB0y-0003VF-Q2 for tcpm@ietf.org; Tue, 25 Sep 2007 10:03:52 -0400 Received: from harrier.viasat.com ([12.198.241.131] helo=VGAEXCH02.hq.corp.viasat.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaB0y-0000Sa-HV for tcpm@ietf.org; Tue, 25 Sep 2007 10:03:52 -0400 Received: from VGAEXCH01.hq.corp.viasat.com ([172.31.1.20]) by VGAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 10:04:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Tue, 25 Sep 2007 10:04:15 -0400 Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B0658B7543@VGAEXCH01.hq.corp.viasat.com> In-Reply-To: <20070925122557.GA13675@grc.nasa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: Acf/cIEGPexxDQapRz6iyg/nsLU3OwAC+pNA From: "Agarwal, Anil" To: , "Fernando Gont" X-OriginalArrivalTime: 25 Sep 2007 14:04:15.0847 (UTC) FILETIME=[F5381770:01C7FF7C] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org All, On Tue 9/25/2007, Wesley Eddy wrote: > I was at the meeting, and I think my hand is included in the=20 > "all MAYs" > above. My personal opinion was that regardless of licensing=20 > terms, I think having known IPR on something that we=20 > recommend all TCP hosts to do is distasteful. Since the=20 > tcpsecure solution isn't generally useful, but only needed=20 > for specific cases, and the antispoof document described=20 > alternatives, I don't feel that the benefits of SHOULD=20 > outweigh the downside, so I'll say "all MAYs" again. I am surprised to hear that these TCP enhancements carry IPR=20 and licensing terms. Are there other standard or standards-track TCP enhancements=20 that require licensing? Anil Anil Agarwal ViaSat Inc. 20511 Seneca Meadows Parkway, Suite 200 Germantown, MD 20876 Anil.Agarwal@viasat.com ViaSat Brings your Network to Life =20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 10:26:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaBME-0000ZX-VZ; Tue, 25 Sep 2007 10:25:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaBMD-0000ZM-NU for tcpm@ietf.org; Tue, 25 Sep 2007 10:25:49 -0400 Received: from harrier.viasat.com ([12.198.241.131] helo=VGAEXCH02.hq.corp.viasat.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaBMD-00015y-CM for tcpm@ietf.org; Tue, 25 Sep 2007 10:25:49 -0400 Received: from VGAEXCH01.hq.corp.viasat.com ([172.31.1.20]) by VGAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 10:26:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [tcpm] New version of tcp-secure draft Date: Tue, 25 Sep 2007 10:26:12 -0400 Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B0658B756B@VGAEXCH01.hq.corp.viasat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [tcpm] New version of tcp-secure draft Thread-Index: Acf/gAYVoeSglGPBQ8eMYee5LtL8wA== From: "Agarwal, Anil" To: X-OriginalArrivalTime: 25 Sep 2007 14:26:12.0814 (UTC) FILETIME=[06314EE0:01C7FF80] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ananth, =20 Here are some (late) comments on draft-ietf-tcpm-tcpsecure-08 - =20 1. Section 1.1 states -=20 "Most modern operating systems have a default window size=20 which usually is applied to most connections. Some applications=20 however may change the window size to better suit the needs of the application".=20 Would be useful to mention that some modern operating=20 systems (Linux) dynamically adapt the receive window size.=20 This somewhat reduces the vulnerability of these attacks. 2. In the first two mitigation techniques, if an attacker=20 injects 3 quick successive RST or SYN packets, it may result in the receiver generating 3 identical ACKs, which in turn may cause the transmitter to perform fast retransmission and reduce cwnd.=20 This is not as bad as a connection reset, but nevertheless it can be quite disruptive, especially for LFNs. Do we need a mechanism to prevent this? An ACK throttling value of 2 per second would be one way to address this =20 Anil Anil Agarwal ViaSat Inc. 20511 Seneca Meadows Parkway, Suite 200 Germantown, MD 20876 Anil.Agarwal@viasat.com =20 ViaSat Brings your Network to Life _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 12:55:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaDeT-0005NC-Ml; Tue, 25 Sep 2007 12:52:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaDeT-0005M6-75 for tcpm@ietf.org; Tue, 25 Sep 2007 12:52:49 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaDeS-0005Qf-OC for tcpm@ietf.org; Tue, 25 Sep 2007 12:52:49 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l8PGq6po024596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 09:52:06 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l8PGq599047409; Tue, 25 Sep 2007 09:52:05 -0700 (PDT) (envelope-from faber) Date: Tue, 25 Sep 2007 09:52:05 -0700 From: Ted Faber To: "Agarwal, Anil" Subject: Re: [tcpm] tcpsecure: how strong to recommend? Message-ID: <20070925165205.GA47871@hut.isi.edu> References: <20070925122557.GA13675@grc.nasa.gov> <0B0A20D0B3ECD742AA2514C8DDA3B0658B7543@VGAEXCH01.hq.corp.viasat.com> Mime-Version: 1.0 In-Reply-To: <0B0A20D0B3ECD742AA2514C8DDA3B0658B7543@VGAEXCH01.hq.corp.viasat.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org, weddy@grc.nasa.gov, Fernando Gont , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0329118974==" Errors-To: tcpm-bounces@ietf.org --===============0329118974== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 25, 2007 at 10:04:15AM -0400, Agarwal, Anil wrote: > All, >=20 > On Tue 9/25/2007, Wesley Eddy wrote: >=20 > > I was at the meeting, and I think my hand is included in the=20 > > "all MAYs" > > above. My personal opinion was that regardless of licensing=20 > > terms, I think having known IPR on something that we=20 > > recommend all TCP hosts to do is distasteful. Since the=20 > > tcpsecure solution isn't generally useful, but only needed=20 > > for specific cases, and the antispoof document described=20 > > alternatives, I don't feel that the benefits of SHOULD=20 > > outweigh the downside, so I'll say "all MAYs" again. >=20 > I am surprised to hear that these TCP enhancements carry IPR=20 > and licensing terms. https://datatracker.ietf.org/ipr/421/ >=20 > Are there other standard or standards-track TCP enhancements=20 > that require licensing? Not so many. You can look for yourself at:=20 https://datatracker.ietf.org/ipr/about/ --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG+Ty0aUz3f+Zf+XsRAgJiAJ0ZyWT9KTFmycqzPJOqqZlg7Ok3+gCg02cH r4293jtZEHxw8KR6b885Vok= =+ih8 -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- --===============0329118974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0329118974==-- From tcpm-bounces@ietf.org Tue Sep 25 13:31:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaEFC-00031x-3K; Tue, 25 Sep 2007 13:30:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaEFA-0002xV-VR for tcpm@ietf.org; Tue, 25 Sep 2007 13:30:45 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaEFA-0006cL-J0 for tcpm@ietf.org; Tue, 25 Sep 2007 13:30:44 -0400 X-IronPort-AV: E=Sophos;i="4.20,296,1186383600"; d="scan'208";a="401681906" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 25 Sep 2007 10:30:44 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8PHUh0g000648; Tue, 25 Sep 2007 10:30:43 -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.12.10/8.12.6) with ESMTP id l8PHUdin027011; Tue, 25 Sep 2007 17:30:39 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); Tue, 25 Sep 2007 10:30:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Tue, 25 Sep 2007 10:30:31 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804051BC4@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <299A2E1C-3704-4F76-B8A3-A3A2C98BA28E@windriver.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: Acf/c7HLhgfFOADJR9ezx8bJmv2JuwAIsArg From: "Anantha Ramaiah \(ananth\)" To: "David Borman" , "Pekka Savola" X-OriginalArrivalTime: 25 Sep 2007 17:30:39.0565 (UTC) FILETIME=[CA7D7FD0:01C7FF99] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1637; t=1190741444; x=1191605444; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ? |Sender:=20; bh=+/g663aMnVAiy/wOLdzP7aLwAR+u88GYTQ2njhhRQF0=; b=ZR9FMA/Cxoq8MFA3FfF8JnWvhrReTEGCb368wkjHFkJoWQc5QleROMY9zg5HPWgbNnxnEKFW x9DlcR2YsMHaW2u8OKySA7Q3gAXlCIc/56K/xbXJjN7TYbMesi06dTJB; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org, Fernando Gont , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Some comments inline...=20 > -----Original Message----- > From: David Borman [mailto:david.borman@windriver.com]=20 > Sent: Tuesday, September 25, 2007 5:55 AM > To: Pekka Savola > Cc: tcpm@ietf.org; Fernando Gont; mallman@icir.org > Subject: Re: [tcpm] tcpsecure: how strong to recommend? >=20 > I voted (3) at the meeting. My vote is with the=20 > understanding that the whole tcpsecure document is *not*=20 > becoming part of the base TCP specification, but is an=20 How does a document become part of the base specification (793 for eg;-)? Does a document which clarfies some things left/out or corrects errors like (1122 for eg;-) become part of the base specs? > optional addition that implementors may choose whether or not=20 > to implement. If they do choose to implement it, then within=20 > that context my vote is for two SHOULDs and a MAY. My understanding is the strength of a proposal is determined by the language used (SHOULD/MUST/MAY etc.,) and that covers everything including guiding an implementor to implement the proposal or not. For eg:- a TCP stack need not implement TCP secure mitigations at all but MUST implement slow start for example.=20 If someone determines (I assume they know what they are doing in most instances ;-) that proposals recommended in a particular RFC is needed either in part/full then they would put resources to get that accomplished in their stack. Isn't the "standard" way ? Or are you saying "base specfication" is something akin to what the roadmap document is talking about under the section "basic functionality"? Confused, -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 14:11:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaEsL-0000vt-7L; Tue, 25 Sep 2007 14:11:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaEsK-0000vo-9Q for tcpm@ietf.org; Tue, 25 Sep 2007 14:11:12 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaEsE-0005Gn-2z for tcpm@ietf.org; Tue, 25 Sep 2007 14:11:12 -0400 Received: from pc6 (1Cust238.tnt29.lnd3.gbr.da.uu.net [62.188.120.238]) by astro.systems.pipex.net (Postfix) with SMTP id D2B95E0007D0; Tue, 25 Sep 2007 19:09:32 +0100 (BST) Message-ID: <05fb01c7ff95$ed6cf7e0$0601a8c0@pc6> From: "Tom Petch" To: , References: <20070924174444.F2C662A7182@lawyers.icir.org> Subject: Re: [tcpm] tcpsecure: how strong to recommend? Date: Tue, 25 Sep 2007 16:47:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -98.6 (---------------------------------------------------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org all SHOULDs (I was not at the meeting) I have been persuaded in the past, during IETF Last Calls, that MAY might as well be MAY NOT in which case it conveys very little. If it is worth expressing in an RFC, then it is worth a SHOULD. Tom Petch ----- Original Message ----- From: "Mark Allman" To: Sent: Monday, September 24, 2007 7:44 PM Subject: [tcpm] tcpsecure: how strong to recommend? > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 14:36:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFFI-0003xe-Dk; Tue, 25 Sep 2007 14:34:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFFG-0003mI-Ld for tcpm@ietf.org; Tue, 25 Sep 2007 14:34:54 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaFFG-0000UW-94 for tcpm@ietf.org; Tue, 25 Sep 2007 14:34:54 -0400 X-IronPort-AV: E=Sophos;i="4.20,296,1186383600"; d="scan'208";a="527942080" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 25 Sep 2007 11:34:53 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8PIYrfQ003387; Tue, 25 Sep 2007 11:34:53 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l8PIXtbL003969; Tue, 25 Sep 2007 18:34:53 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 11:34:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Tue, 25 Sep 2007 11:34:50 -0700 Message-ID: <13D1EAB852BE194C94773A947138483D041D8B78@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20070925024708.1E6CA2A7A80@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: Acf/H5bWN+IrF2Y7QUOa8GQzOraOFwAglvmw From: "Mitesh Dalal \(mdalal\)" To: , "Joe Touch" , X-OriginalArrivalTime: 25 Sep 2007 18:34:50.0960 (UTC) FILETIME=[C219BD00:01C7FFA2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1325; t=1190745293; x=1191609293; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mdalal@cisco.com; z=From:=20=22Mitesh=20Dalal=20\(mdalal\)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ?=20 |Sender:=20; bh=gWTMZc+MPpWjMYjgQvm8d5yF3b7YfK4nu3UU0/xKKNY=; b=mfXpNCzcF9yw05vZWB98maBJqrUD+Pu8EUx9qkt/6rho2k9Y+NM7B5yLyoWBdnk6tyoKb4On SMfOsFYl7lNfAmzs3ZyWL1VaWcQMtBD/L5KmWymm7TXuw1VIJnYFmk/CsP9xhaAkeEYnWWoRCe Q9iw1+uwievDc8iAavEbpl238=; Authentication-Results: sj-dkim-1; header.From=mdalal@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org A point to note is that we neither obsolete nor update rfc793, so if we make a requirement as SHOULD or MUST does not cause an implementation to go out of spec (just as in RFC3168 makes SHOULD/MUST recommendations, but does not mean that all rfc793 implementations are out of spec) The whole discussion becomes relevant only if we are really updating rfc793, so as long as you see these changes as standalone, the question of SHOULD/MUST/MAY become self explanatory in the right context.=20 So, in that sense I propose the changes as MUST. If an implementation claims compliance with these changes, than this (MUST) is the way it has to be implemented. my 0.02 Mitesh > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org]=20 > Sent: Monday, September 24, 2007 7:47 PM > To: Joe Touch > Cc: tcpm@ietf.org > Subject: Re: [tcpm] tcpsecure: how strong to recommend?=20 >=20 >=20 > > I'd encourage others to weigh in on this. I'm uncomfortable=20 > with our=20 > > making recommendations to change TCP's fundamental behavior as a=20 > > SHOULD on the basis of a handful of representatives. >=20 > Joe, I hear you. Ted and I chatted today and are also a bit=20 > leery here. We'd very much love to hear from others with opinions. >=20 > allman >=20 >=20 >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 14:49:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFSx-0000WK-PL; Tue, 25 Sep 2007 14:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFSx-0000WF-CE for tcpm@ietf.org; Tue, 25 Sep 2007 14:49:03 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaFSs-0006Mu-01 for tcpm@ietf.org; Tue, 25 Sep 2007 14:49:03 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8PImpPe011508; Tue, 25 Sep 2007 11:48:51 -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 6005AFE2A1C; Tue, 25 Sep 2007 14:48:45 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2C7682A88A7; Tue, 25 Sep 2007 14:47:38 -0400 (EDT) To: "Anantha Ramaiah (ananth)" From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <0C53DCFB700D144284A584F54711EC5804051BC4@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Tue, 25 Sep 2007 14:47:38 -0400 Message-Id: <20070925184738.2C7682A88A7@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: tcpm@ietf.org, David Borman , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0344505627==" Errors-To: tcpm-bounces@ietf.org --===============0344505627== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hat off ... This is a lot of hang wringing mumbo-jumbo, I think. It seems to me ... + If a standards track document says "a TCP SHOULD do X" then as a particular TCP evolves it really ought to do X unless the implementers have a very good reason not to do X. + If a standards track document says "a TCP MAY do X" then as a particular TCP evolves the implementers have discretion to do X or not to do X based on their understanding of the issues. + If a standards track document says "a TCP SHOULD do X subject to conditions Y or scope Z" then as a particular TCP implementation evolves it really ought to do X if it falls within the given conditions or scope. Why is this harder than that? Hat on ... It seems that currently the first two bullets apply to tcpsecure. That is, the document does not have any scoping or conditions. Lars (and others) has suggested that perhaps we need to add some scoping to the document through an applicability statement. That is certainly an option. If folks think that we should be adding such an applicability statement before worrying about SHOULD vs. MAY then please say so. (It seems to me that thus far that has been a minority position. I am happy to change my view of this based WG input, naturally.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG+VfKWyrrWs4yIs4RAhgsAJ9OXWQMCfr1CSoZzZSpozyQP6+c6QCcDr4T 4K4ABmekNE5arFkguzvkNDs= =36+F -----END PGP SIGNATURE----- --=_bOundary-- --===============0344505627== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0344505627==-- From tcpm-bounces@ietf.org Tue Sep 25 15:01:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFdq-0001KG-RI; Tue, 25 Sep 2007 15:00:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFdp-0001K9-Kz for tcpm@ietf.org; Tue, 25 Sep 2007 15:00:17 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaFdh-0006eJ-8L for tcpm@ietf.org; Tue, 25 Sep 2007 15:00:15 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1IaFdE-0000Gs-00; Tue, 25 Sep 2007 14:59:40 -0400 From: Tim Shepard To: "Mitesh Dalal \(mdalal\)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-reply-to: Your message of Tue, 25 Sep 2007 11:34:50 -0700. <13D1EAB852BE194C94773A947138483D041D8B78@xmb-sjc-21c.amer.cisco.com> Date: Tue, 25 Sep 2007 14:59:40 -0400 Message-Id: X-Spam-Score: 3.3 (+++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tcpm@ietf.org, Joe Touch , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > The whole discussion becomes relevant only if we are really updating > rfc793, so as long as you see these changes as standalone, the question > of SHOULD/MUST/MAY become self explanatory in the right context. > > So, in that sense I propose the changes as MUST. If an implementation > claims > compliance with these changes, than this (MUST) is the way it has to be > implemented. I think we've lost something important with MAY/SHOULD/MUST stuff. Recall Lars Eggert's pointing out the need for an applicability statement (in general and in particular). It seems the mitigations described in this draft should be implemented in any TCP which is going to be used for things which use TCP in such a way that they will be vulnerable (where the IP addresses of both ends and the port number of one end are knowable by an attacker) *or* something else could be done to reduce vulnerability to such an attack. But its not completely clear to me that here we are trying to define a protocol, the sort of thing which needs things like MAY/SHOULD/MUST to ensure that interoperability goals will be met. A somewhat serious security problem was discovered some time ago. This draft documents one vendor's approach to solving this problem. There are other ways of solving this problem. It's not clear that a standard is needed here to ensure interoperability of systems. What is our goal here with this document? Can the English word "should" be used in an RFC (without making it uppercase)? I'd be happy publishing this document as informational and not sweating the MAY/SHOULD/MUST stuff. Just make them lowercase and make the text make sense. How's BTNS coming along? Will we be seeing BGP over BTNS anytime soon? (I've not been following BTNS too closely recently). -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 15:38:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaGDt-0003Qr-4B; Tue, 25 Sep 2007 15:37:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaGDr-0003M6-Qn for tcpm@ietf.org; Tue, 25 Sep 2007 15:37:31 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaGDl-000858-Hq for tcpm@ietf.org; Tue, 25 Sep 2007 15:37:31 -0400 Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8PJaOKs020840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 12:36:25 -0700 (PDT) Message-ID: <46F962BA.2020901@isi.edu> Date: Tue, 25 Sep 2007 12:34:18 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <20070925184738.2C7682A88A7@lawyers.icir.org> In-Reply-To: <20070925184738.2C7682A88A7@lawyers.icir.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: David Borman , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Allman wrote: > Hat off ... > > This is a lot of hang wringing mumbo-jumbo, I think. It seems to me ... > > + If a standards track document says "a TCP SHOULD do X" then as a > particular TCP evolves it really ought to do X unless the > implementers have a very good reason not to do X. > > + If a standards track document says "a TCP MAY do X" then as a > particular TCP evolves the implementers have discretion to do X or > not to do X based on their understanding of the issues. > > + If a standards track document says "a TCP SHOULD do X subject to > conditions Y or scope Z" then as a particular TCP implementation > evolves it really ought to do X if it falls within the given > conditions or scope. > > Why is this harder than that? The other nuance is: if you do A you MUST do B i.e., dependencies of the choices within the protocol. That's useful to capture, even using MUST/MAY/SHOULDs, but it should be clear enough from the textual context. > Hat on ... > > It seems that currently the first two bullets apply to tcpsecure. That > is, the document does not have any scoping or conditions. Lars (and > others) has suggested that perhaps we need to add some scoping to the > document through an applicability statement. That is certainly an > option. If folks think that we should be adding such an applicability > statement before worrying about SHOULD vs. MAY then please say so. (It > seems to me that thus far that has been a minority position. I am happy > to change my view of this based WG input, naturally.) I think that MAY is fine without conditions. I think that SHOULD should always have conditions - even if to explicitly state "all TCPs SHOULD" in the most general case. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+WK6E5f5cImnZrsRAiuvAKD2eS2cYG2WdY18FUzPUWLxq+KMngCdFXqy OFp/CYbShaFEFJOqiE0c0eI= =+FfC -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 15:38:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaGEE-0005Y1-9h; Tue, 25 Sep 2007 15:37:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaGEC-0005OO-Ke for tcpm@ietf.org; Tue, 25 Sep 2007 15:37:52 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaGEC-0002yi-8Y for tcpm@ietf.org; Tue, 25 Sep 2007 15:37:52 -0400 Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8PJbbxx021056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 12:37:37 -0700 (PDT) Message-ID: <46F96303.1020701@isi.edu> Date: Tue, 25 Sep 2007 12:35:31 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tom Petch Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <20070924174444.F2C662A7182@lawyers.icir.org> <05fb01c7ff95$ed6cf7e0$0601a8c0@pc6> In-Reply-To: <05fb01c7ff95$ed6cf7e0$0601a8c0@pc6> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Petch wrote: > all SHOULDs (I was not at the meeting) > > I have been persuaded in the past, during IETF Last Calls, that MAY might as > well be MAY NOT in which case it conveys very little. If it is worth expressing > in an RFC, then it is worth a SHOULD. There are plenty of RFCs that describe MAYs, FWIW. MAY means that it's permissible and compliant to do something. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+WMDE5f5cImnZrsRAiXgAJ9gDml6tYxfXo5h1OQ7RW7JkLAUygCgzdHH bcAFPPWHtx4akV5CUZXdn7M= =H/Et -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 17:17:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaHkN-0003jF-S7; Tue, 25 Sep 2007 17:15:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaHkM-0003j8-9U for tcpm@ietf.org; Tue, 25 Sep 2007 17:15:10 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaHkG-000294-3P for tcpm@ietf.org; Tue, 25 Sep 2007 17:15:10 -0400 X-IronPort-AV: E=Sophos;i="4.20,297,1186383600"; d="scan'208";a="224973012" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 25 Sep 2007 14:14:57 -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 l8PLEvxi019099; Tue, 25 Sep 2007 14:14:57 -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.12.10/8.12.6) with ESMTP id l8PLEb7p013007; Tue, 25 Sep 2007 21:14:47 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); Tue, 25 Sep 2007 14:14:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Tue, 25 Sep 2007 14:14:08 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804051D95@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20070925184738.2C7682A88A7@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: Acf/pLtyj1yaRiUITMGCv6jTRt9eYAAEUT4Q From: "Anantha Ramaiah \(ananth\)" To: X-OriginalArrivalTime: 25 Sep 2007 21:14:17.0361 (UTC) FILETIME=[081EB010:01C7FFB9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1574; t=1190754897; x=1191618897; 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]=20tcpsecure=3A=20how=20strong=20to=20recommend ?=20 |Sender:=20; bh=OEkJinNEqlcJorIbT2taiai9dt+XLl2/b1b02qRzTE0=; b=SGDdekiH5V4Ut8azPU+eNKANmLu3r5Ke69vfBd5u6i/8XoaM6bB/Pte54ayaih1ZKt4xdH2Y QVZQTLwsUR4JD3N+7fDAuoeNHXBkj5HhDFbDLSb6Cqg2oyqInwHQD99i; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tcpm@ietf.org, David Borman , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org >=20 >=20 > Hat off ...=20 >=20 > This is a lot of hang wringing mumbo-jumbo, I think. It=20 > seems to me ... >=20 > + If a standards track document says "a TCP SHOULD do X" then as a > particular TCP evolves it really ought to do X unless the > implementers have a very good reason not to do X. Since, all these discussions about started due to TCP secure, let me use the same as an example. There is nothing wrong in making all mitigations SHOULD since the "very good reason" can be one of :- - I don't care about security/robustness of TCP connections and hence my products don't need to implement these. - well I do care about security but I always use additional protection like MD5 or IPsec and hence implementing this is optional. I'll think about it. - I like the mitigations in the draft and I see them lightweight and I'll go ahead and implement them, but since these are tagged SHOULD I may have a knob to control this behaviour. - I definetely would want to implement these. Even though it is a SHOULD, to me it is like a MUST. So what I am tryng to say is: it is upto the implementers to interpret and implement it if they wish to do so. Saying SHOULD is not an issue since it gives enough leeway for all of the above scenarios. But I am open to the idea of adding a generic applicability statement like : "these mitigations are useful in blah blah... Conditions etc., " Already if I remember correctly we do have some text to that effect in the draft, but we can polish it further or formalize it. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 17:51:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaIIN-00058I-KO; Tue, 25 Sep 2007 17:50:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaIIL-000582-RR for tcpm@ietf.org; Tue, 25 Sep 2007 17:50:18 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaIIL-0006d7-5D for tcpm@ietf.org; Tue, 25 Sep 2007 17:50:17 -0400 Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8PLnvR4021984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 14:49:57 -0700 (PDT) Message-ID: <46F98207.7030902@isi.edu> Date: Tue, 25 Sep 2007 14:47:51 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC5804051D95@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5804051D95@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: tcpm@ietf.org, David Borman , Fernando Gont , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anantha Ramaiah (ananth) wrote: >> >> Hat off ... >> >> This is a lot of hang wringing mumbo-jumbo, I think. It >> seems to me ... >> >> + If a standards track document says "a TCP SHOULD do X" then as a >> particular TCP evolves it really ought to do X unless the >> implementers have a very good reason not to do X. > > Since, all these discussions about started due to TCP secure, let me use > the same as an example. There is nothing wrong in making all mitigations > SHOULD since the "very good reason" can be one of :- ... I'll number these for references: #1 > - I don't care about security/robustness of TCP connections and hence my > products don't need to implement these. #2 > - well I do care about security but I always use additional protection > like MD5 or IPsec and hence implementing this is optional. I'll think > about it. #3 > - I like the mitigations in the draft and I see them lightweight and > I'll go ahead and implement them, but since these are tagged SHOULD I > may have a knob to control this behaviour. #4 > - I definetely would want to implement these. Even though it is a > SHOULD, to me it is like a MUST. > > So what I am tryng to say is: it is upto the implementers to interpret > and implement it if they wish to do so. Saying SHOULD is not an issue > since it gives enough leeway for all of the above scenarios. I don't think SHOULD covers #1 very well above, and it arguably doesn't voer case 2 either. SHOULD really intends to mean "MUST unless you know you know a specific reason that would be undesirable". That's why I think some of us (myself included) prefer MAY for all (with the caveat that there can be MAY for the whole set, and the additional relative requirements, i.e., If you do A, you MUST do B.) Joe > > But I am open to the idea of adding a generic applicability statement > like : "these mitigations are useful in blah blah... Conditions etc., " > Already if I remember correctly we do have some text to that effect in > the draft, but we can polish it further or formalize it. > > -Anantha > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+YIHE5f5cImnZrsRAtRJAJ9SF22zVHa2fXAJtLgwgp6q9etZWACggnNJ 5DsUOKhqLZK7Tv769pvwz8o= =wuYp -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 25 18:13:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaIdz-0008Nn-BN; Tue, 25 Sep 2007 18:12:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaIdy-0008NM-7m for tcpm@ietf.org; Tue, 25 Sep 2007 18:12:38 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaIdx-0007gU-Rd for tcpm@ietf.org; Tue, 25 Sep 2007 18:12:38 -0400 Received: from [128.9.176.224] (c2-vpn07.isi.edu [128.9.176.224]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8PMCH2q027221; Tue, 25 Sep 2007 15:12:17 -0700 (PDT) Message-ID: <46F987B7.3030305@isi.edu> Date: Tue, 25 Sep 2007 15:12:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tim Shepard Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: In-Reply-To: X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0653725548==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0653725548== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCD204005FD316F962F2C0A5B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCD204005FD316F962F2C0A5B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tim Shepard wrote: > How's BTNS coming along? Will we be seeing BGP over BTNS anytime soon= ? > (I've not been following BTNS too closely recently). See the Goals and Milestones at: http://www.ietf.org/html.charters/btns-charter.html Joe --------------enigCD204005FD316F962F2C0A5B 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 iD4DBQFG+Ye7E5f5cImnZrsRAnO9AJjQbBq0M5iHRXRtStchTs7ZJTk1AJ9P/GWN TNrcDIup4ez0jgOnTNvuGg== =UcwS -----END PGP SIGNATURE----- --------------enigCD204005FD316F962F2C0A5B-- --===============0653725548== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0653725548==-- From tcpm-bounces@ietf.org Wed Sep 26 07:46:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVIh-000348-GQ; Wed, 26 Sep 2007 07:43:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVIg-0002lo-Im for tcpm@ietf.org; Wed, 26 Sep 2007 07:43:30 -0400 Received: from [2002:425c:4292::1] (helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaVIZ-0007pt-IR for tcpm@ietf.org; Wed, 26 Sep 2007 07:43:24 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1IaVI6-0005N1-00; Wed, 26 Sep 2007 07:42:54 -0400 From: Tim Shepard To: Joe Touch Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-reply-to: Your message of Tue, 25 Sep 2007 15:12:07 -0700. <46F987B7.3030305@isi.edu> Date: Wed, 26 Sep 2007 07:42:53 -0400 Message-Id: X-Spam-Score: -0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > > How's BTNS coming along? Will we be seeing BGP over BTNS anytime soon? > > (I've not been following BTNS too closely recently). > > See the Goals and Milestones at: > http://www.ietf.org/html.charters/btns-charter.html Cool. But that is only a (partial) answer to my first question. From the status of Goals and Milestones on that IETF WG charter page, I cannot tell if the result of the BTNS WG is something that is sufficiently far along that "go do BTNS" is a viable alternative to this "tcpsecure" draft. Presumably I could read all the drafts that are there and form my own opnion, but the queue of things that I ought to read soon is much deeper than what I will be able to read soon. (For those attempting to follow along... I believe the need that triggered this tcpsecure draft was also (one of?) the trigger(s) that led to the BTNS WG effort. This tcpsecure draft is a collection of hacks (which appear to solve the problems as we understand them now) while the BTNS effort was started in an attempt to solve the problem in an architecturally correct and more robust way.) At some point there's a decision to be made, recommend what's in the tcpsecure draft, or recommend what BTNS has produced. So I ask: is BTNS succeeding such that it is a viable alternative to this tcpsecure draft? -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 26 09:54:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXK8-00052q-CX; Wed, 26 Sep 2007 09:53:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXK7-0004fV-Bv for tcpm@ietf.org; Wed, 26 Sep 2007 09:53:07 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaXK3-0007iN-IB for tcpm@ietf.org; Wed, 26 Sep 2007 09:53:04 -0400 Received: from kivilampi-30.cs.helsinki.fi (kivilampi-30.cs.helsinki.fi [128.214.9.42]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 26 Sep 2007 16:52:45 +0300 id 000805EF.46FA642D.00004FC3 Received: by kivilampi-30.cs.helsinki.fi (Postfix, from userid 50795) id A6A69EAFEF; Wed, 26 Sep 2007 16:52:44 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by kivilampi-30.cs.helsinki.fi (Postfix) with ESMTP id 98768EAFEE; Wed, 26 Sep 2007 16:52:44 +0300 (EEST) Date: Wed, 26 Sep 2007 16:52:43 +0300 (EEST) From: "=?ISO-8859-1?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@kivilampi-30.cs.helsinki.fi To: Pasi Sarolahti Subject: Re: [tcpm] Re: draft-ietf-tcpm-rfc4138bis-00 In-Reply-To: Message-ID: References: <200709111615.SAA24923@TR-Sys.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_courier-20574-1190814783-0001-2" Content-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: =?ISO-8859-1?Q?ext_Alfred_H=CEnes?= , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-20574-1190814783-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-ID: X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.53.3 ...I shuffled it a bit. On Tue, 25 Sep 2007, Pasi Sarolahti wrote: > On Sep 11, 2007, at 19:15, ext Alfred H=CEnes wrote: > > >Since I do not have detailed knowledge regarding the degree of > >SACK support and actual use in the internet now, I admittedly > >just had followed your arguments. > > > >But, if it turns ot that SACK will gain, or already has gained, > >significant importance, it might indeed be reasonable to keep > >the SACK variant of F-RTO in 4138bis. To this end, it might be > >useful to consider and evaluate the role of SACK for the evolution > >of other aspects of TCP (and other transport protocols); if it > >turns out, e.g., that SACK would be quite useful and important > >for the expected predominant response algoritms for F-RTO anyway, > >that should be taken as a firm indication that the SACK variant > >of F-RTO should be left in the document. > > First, one note of clarification: a TCP that uses SACK can still use th= e basic > version of F-RTO based on cumulative acknowledgements just fine. The SA= CK > variant of F-RTO was intended to improve cases where duplicate ACKs (fo= r > reordering, for example) prevent detection of spurious RTO with the bas= ic > algorithm. To my understanding such cases are quite rare, so the additi= onal > benefit might not be too significant. Also if there's a loss very close after the delayed packet, SACK version can first detect RTO as spurious and then TCP recovers after three dupacks. How likely that is, I don't know. > Also, the SACK version of F-RTO has not been included in all > implementations that have the basic version > (for example Linux distribution has had only the basic version). ...That's only partially valid because since 2.6.22 Linux has included both versions (though both off by default). Its SACK version includes features discussed in 4138's Appendix B. From 2.6.24 onward it will enable SACK version by default. > I have started to hesitate with my opinion on the SACK variant. We prop= osed > dropping out the SACK variant from the 4138bis draft, because it seemed= that > it has not been as thoroughly analyzed as the basic F-RTO. > > However, after I mentioned about dropping SACK in the Chicago presentat= ion, it > turned out in the hallway discussions that there are implementations of= the > SACK variant in real use. So if it seems that the consensus is for keep= ing the > SACK variant in 4138bis, that's fine with me as well. I'd be happy to h= ear > more comments on this! Quite clearly using SACK blocks improves FRTO's accuracy in detection as they are rather strong indication what really arrived. However, it adds some challenges to aggressive response usage because then lying in SACK blocks should also be addressed in Security Considerations, especially as= "because the sender will have an incorrect state, it cannot retransmit the segment that has never reached the receiver" does not hold like it does with SND.UNA. Yet, as long as FRTO is accompanied with a conservativ= e response, I don't see how the receiver could have meaningful benefits fro= m lying, whereas unnecessary retransmissions are more accurately mitigated. -- i. --=_courier-20574-1190814783-0001-2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --=_courier-20574-1190814783-0001-2-- From tcpm-bounces@ietf.org Wed Sep 26 10:03:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXTL-0000VJ-VN; Wed, 26 Sep 2007 10:02:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXTK-0000Ur-Nn for tcpm@ietf.org; Wed, 26 Sep 2007 10:02:38 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaXTK-00083Z-64 for tcpm@ietf.org; Wed, 26 Sep 2007 10:02:38 -0400 Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8QE1ufj025454; Wed, 26 Sep 2007 07:01:56 -0700 (PDT) Message-ID: <46FA664A.1050803@isi.edu> Date: Wed, 26 Sep 2007 07:01:46 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tim Shepard Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: In-Reply-To: X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1231014734==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1231014734== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD8AD63D04C3C322F0CAF066D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD8AD63D04C3C322F0CAF066D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tim Shepard wrote: >>> How's BTNS coming along? Will we be seeing BGP over BTNS anytime so= on? >>> (I've not been following BTNS too closely recently). >> See the Goals and Milestones at: >> http://www.ietf.org/html.charters/btns-charter.html >=20 >=20 > Cool. But that is only a (partial) answer to my first question. From > the status of Goals and Milestones on that IETF WG charter page, I > cannot tell if the result of the BTNS WG is something that is > sufficiently far along that "go do BTNS" is a viable alternative to > this "tcpsecure" draft. Presumably I could read all the drafts that > are there and form my own opnion, but the queue of things that I ought > to read soon is much deeper than what I will be able to read soon. >=20 > (For those attempting to follow along... I believe the need that > triggered this tcpsecure draft was also (one of?) the trigger(s) that > led to the BTNS WG effort. This tcpsecure draft is a collection of > hacks (which appear to solve the problems as we understand them now) > while the BTNS effort was started in an attempt to solve the problem > in an architecturally correct and more robust way.) FWIW: tcpsecure reduces the impact of attacks on TCP that presume knowledge of the socket pair (src/dst IP, src/dst port), the impetus of which was attacks on BGP as noted in RFC4953 (antispoof) discusses protections for such services, and more direct protections using authentication mechanisms such as TCP/MD5 (which we have a group revising - stay tuned...) and IPsec. IPsec is sometimes not used in routers because of the need to configure preshared keys or certificate authority information; BTNS enables IPsec without either BTNS has a large number of potential uses beyond BGP, though. TCP/MD5 and its alternates - despite the formers similar need for preshared keys - may be more likely to be more widely used for the BGP case. I.e., as was noted in antispoof, there are many ways to address this problem, and the problem is of impact only for certain connections. > At some point there's a decision to be made, recommend what's in the > tcpsecure draft, or recommend what BTNS has produced. Or the successor to TCP/MD5, or existing IPsec - and that recommendation will probably involve collaboration with the Security Area. > So I ask: is BTNS succeeding such that it is a viable alternative to > this tcpsecure draft? One of many alternatives, yes. The only alternative, no. Joe --------------enigD8AD63D04C3C322F0CAF066D 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 iD8DBQFG+mZPE5f5cImnZrsRAnrzAJ9sgWar3rUisAC7cplAyVfQTJphkgCguiK2 sVylG61dJJBToPvaiLuR3pU= =IXky -----END PGP SIGNATURE----- --------------enigD8AD63D04C3C322F0CAF066D-- --===============1231014734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1231014734==-- From tcpm-bounces@ietf.org Wed Sep 26 10:43:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaY5y-0002rp-3z; Wed, 26 Sep 2007 10:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaY5w-0002ra-UK for tcpm@ietf.org; Wed, 26 Sep 2007 10:42:32 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaY5v-0003p0-Ml for tcpm@ietf.org; Wed, 26 Sep 2007 10:42:32 -0400 X-IronPort-AV: E=Sophos;i="4.20,302,1186383600"; d="scan'208";a="20089643" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 26 Sep 2007 07:42:31 -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 l8QEgVOZ026903; Wed, 26 Sep 2007 07:42:31 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8QEgUWO019463; Wed, 26 Sep 2007 14:42:30 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 Sep 2007 07:41:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Wed, 26 Sep 2007 07:41:52 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804052052@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgAMx227pTakmMpTgi2Vowi/IMTbQAFICOg From: "Anantha Ramaiah \(ananth\)" To: "Tim Shepard" , "Joe Touch" X-OriginalArrivalTime: 26 Sep 2007 14:41:53.0199 (UTC) FILETIME=[611E6BF0:01C8004B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3356; t=1190817751; x=1191681751; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ?=20 |Sender:=20; bh=SV2po3OJpZwtXTZJH8SnceoCVt3wiNbVhvfkPrpHaVE=; b=FJy6dHo9cIwAdbqukkt+lhAYoOtuWtjg7Xr80rFrcCwQUaPziU1q0GsAmOVZwtnjRSw+HTih MEXtsySfa7sM4vsDo/B65vWiTyzyNUIBktFPL38n2gRmrBxWiCOe8o2A; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Few points :- - It is true that TCP secure recommendations might be useful for long lived sessions like BGP. But there are many applications using TCP which also could benefit from the proposed changes. The TCP secure changes needs to be viewed as a standalone thing, since it focusses in providing robustness to TCP connections w.r.t some spoofing attacks.=20 - TCP secure changes are not going to solve the "world hunger problem". Ipsec and TCP secure are completely orthogonal since Ipsec is generic security solution with it's own pros and cons whereas TCP secure attempts to illustrate some known issues w.r.t some TCP spoofing attacks and proposes mitigations to the same. - The WG is also talking about replacing the TCP MD5 with a more generic TCP security algorithms. This came out of the need to provide security at layer 4. I know some people would dis-agree but that is a different story. - TCP secure, TCP MD5, TCP advanced security algorithms, IPsec are all different tools with varying degrees of complexity and usage. A user can chose to use one of them depending on his/her requirements. Telling people to only use IPsec is akin to saying "always fly in business class". Yes I have used this analogy before, but this is one whih popped up in mind after today's coffee :-) So, I would not draw some comparisions between TCP secure and other "security" solutions including BTNS etc., These need to be viewed upon independently. Well, I am speaking out of experience resulting from dealing with working on many products which use TCP and confronting the differing requirements imposed by those, so needless to say, OMMV. -Anantha >=20 > > > How's BTNS coming along? Will we be seeing BGP over=20 > BTNS anytime soon? > > > (I've not been following BTNS too closely recently). > >=20 > > See the Goals and Milestones at: > > http://www.ietf.org/html.charters/btns-charter.html >=20 >=20 > Cool. But that is only a (partial) answer to my first=20 > question. From the status of Goals and Milestones on that=20 > IETF WG charter page, I cannot tell if the result of the BTNS=20 > WG is something that is sufficiently far along that "go do=20 > BTNS" is a viable alternative to this "tcpsecure" draft. =20 > Presumably I could read all the drafts that are there and=20 > form my own opnion, but the queue of things that I ought to=20 > read soon is much deeper than what I will be able to read soon. >=20 > (For those attempting to follow along... I believe the need=20 > that triggered this tcpsecure draft was also (one of?) the=20 > trigger(s) that > led to the BTNS WG effort. This tcpsecure draft is a collection of > hacks (which appear to solve the problems as we understand=20 > them now) while the BTNS effort was started in an attempt to=20 > solve the problem in an architecturally correct and more robust way.) >=20 > At some point there's a decision to be made, recommend what's=20 > in the tcpsecure draft, or recommend what BTNS has produced. >=20 > So I ask: is BTNS succeeding such that it is a viable=20 > alternative to this tcpsecure draft? >=20 > -Tim Shepard > shep@alum.mit.edu >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 26 12:47:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaa1w-0001qa-4q; Wed, 26 Sep 2007 12:46:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaa1u-0001iY-U6 for tcpm@ietf.org; Wed, 26 Sep 2007 12:46:30 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iaa1u-00059s-8S for tcpm@ietf.org; Wed, 26 Sep 2007 12:46:30 -0400 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 17:46:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Wed, 26 Sep 2007 17:46:49 +0100 Message-ID: In-Reply-To: <44F9F627-9A49-4A63-9F38-0006F1FE2BDF@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: Acf/e/jEdAyxcSypQ9uxLKw1OAOZuAA3nHnQ From: To: , X-OriginalArrivalTime: 26 Sep 2007 16:46:27.0294 (UTC) FILETIME=[C806CFE0:01C8005C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Two things that seem clear from this quite long email thread: 1) many of the people expressing opinions on this are the same ones that expressed opinions at the meeting in Chicago 2) there is definite lack of agreement on the meaning of SHOULD and MAY (MUST seems pretty clear). It almost seems that there is a need for a new level of recommendation somewhere between SHOULD (which many people seem to take to mean "MUST unless you have a good reason not to") and MAY (which some people take to mean "may do if you choose to"). What is lacking (as I think Tim was driving at) is a word to mean "we advise you to do this but don't want to obligate you". Obviously some of this confusion can be reduced if proper applicability statements are used as described by Lars below. For what its worth I am torn between options 2) and 3). Option 3) is correct if the applicability is clearly defined to those TCPs where there is significant risk of harm from these attacks Toby ________________________________________________________________________ ____ Toby Moncaster, Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734=20 -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: 25 September 2007 14:54 To: ext Joe Touch Cc: tcpm@ietf.org; mallman@icir.org Subject: Re: [tcpm] tcpsecure: how strong to recommend? Hi, On 2007-9-25, at 1:34, ext Joe Touch wrote: > I'd encourage others to weigh in on this. I'm uncomfortable with our=20 > making recommendations to change TCP's fundamental behavior as a=20 > SHOULD on the basis of a handful of representatives. this brings up an important point we need to clarify. The tcpsecure document contains a technical specification for multiple TCP mechanisms to protect against certain attacks. However, RFC 2026 recommends that technical specifications should also come with a statement of applicability, i.e., something that says when the technical specification should or should not be used. =20 Many documents don't have this, and often that isn't an issue. The tcpsecure document is missing this piece, too, but in this case I believe this is causing some confusion. For some folks, this lack of a clear applicability statement means that the tcpsecure mechanisms become part of the "must-implement" set of TCP. To other folks, the MUST/SHOULD/MAY in the current document *are* a kind of applicability statement. I think it would be helpful if we would tease apart applicability statement and technical specification. What were missing is consensus on the applicability of the proposed set of mechanisms. During the discussion around this document, I've heard basically two choices being expressed: (1) all TCP stacks should implement tcpsecure (2) only TCP stacks that expect to support a significant number of connections for which the described attacks are possible should implement tcpsecure This is important to scope the discussion we're currently having on SHOULD vs. MAY. If the applicability is (1), a SHOULD with its should-have-a-really- good-reason-to-ignore semantics is a pretty strong statement that affects all stacks. Whereas if the applicability is (2) or something else that is more restricted than (1), a SHOULD is essentially without effect for stacks that don't consider themselves to fall under the conditions stated. Lars PS: Here is the relevant section from RFC2026: 3.1 Technical Specification (TS) A Technical Specification is any description of a protocol, service, procedure, convention, or format. It may completely describe all of the relevant aspects of its subject, or it may leave one or more parameters or options unspecified. A TS may be completely self- contained, or it may incorporate material from other specifications by reference to other documents (which might or might not be Internet Standards). A TS shall include a statement of its scope and the general intent for its use (domain of applicability). Thus, a TS that is inherently specific to a particular context shall contain a statement to that effect. However, a TS does not specify requirements for its use within the Internet; these requirements, which depend on the particular context in which the TS is incorporated by different system configurations, are defined by an Applicability Statement. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 26 14:16:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabPJ-0007cB-Vh; Wed, 26 Sep 2007 14:14:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabPI-0007be-Gc for tcpm@ietf.org; Wed, 26 Sep 2007 14:14:44 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IabPI-0000WX-2m for tcpm@ietf.org; Wed, 26 Sep 2007 14:14:44 -0400 Received: from [75.214.61.9] (9.sub-75-214-61.myvzw.com [75.214.61.9]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8QIE5Tb024128; Wed, 26 Sep 2007 11:14:06 -0700 (PDT) Message-ID: <46FAA166.8020403@isi.edu> Date: Wed, 26 Sep 2007 11:13:58 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC5804052052@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5804052052@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tcpm@ietf.org, Tim Shepard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0769757647==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0769757647== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE9599FBD810E47AF2BCA222D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE9599FBD810E47AF2BCA222D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > Few points :- >=20 > - It is true that TCP secure recommendations might be useful for long > lived sessions like BGP. But there are many applications using TCP whic= h > also could benefit from the proposed changes. As an aside, it would be useful to provide in your doc an example of such an application, e.g., where the endpoints and port numbers are known or reasonably guessable. > The TCP secure changes > needs to be viewed as a standalone thing, since it focusses in providin= g > robustness to TCP connections w.r.t some spoofing attacks.=20 The real point is that spoofing isn't a standalone thing. Putting protections into TCP without locking down ICMP isn't sufficient, and inferring authentication from header properties just narrows the window of attack. > - TCP secure, TCP MD5, TCP advanced security algorithms, IPsec are all > different tools with varying degrees of complexity and usage. A user ca= n > chose to use one of them depending on his/her requirements. Telling > people to only use IPsec is akin to saying "always fly in business > class". Yes I have used this analogy before, but this is one whih poppe= d > up in mind after today's coffee :-) If we agree that users should be able to choose the solution that fits, let's go with MAYs all around. Otherwise, aren't you dictating your solution as fitting everyone's needs= ? Joe --------------enigE9599FBD810E47AF2BCA222D 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 iD8DBQFG+qFmE5f5cImnZrsRAhaQAJ0cOTsQ4d6BL1AkmI353MnhR8UttwCg955b C3EPQpG1yz/xC2rYo6BAIlk= =1ukI -----END PGP SIGNATURE----- --------------enigE9599FBD810E47AF2BCA222D-- --===============0769757647== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0769757647==-- From tcpm-bounces@ietf.org Wed Sep 26 14:34:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabhM-0006Om-41; Wed, 26 Sep 2007 14:33:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabhK-0006Of-Pg for tcpm@ietf.org; Wed, 26 Sep 2007 14:33:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IabhK-0001pV-Ah for tcpm@ietf.org; Wed, 26 Sep 2007 14:33:22 -0400 X-IronPort-AV: E=Sophos;i="4.21,198,1188802800"; d="scan'208";a="225631549" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Sep 2007 11:33:21 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8QIXLxV023581; Wed, 26 Sep 2007 11:33:21 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8QIXL8p024310; Wed, 26 Sep 2007 18:33:21 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 Sep 2007 11:33:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Wed, 26 Sep 2007 11:33:19 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804052217@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <46FAA166.8020403@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgAaR/I8v3Z5aKtTKKO00yNZzUhqAAAF7uA From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" X-OriginalArrivalTime: 26 Sep 2007 18:33:21.0393 (UTC) FILETIME=[B720A610:01C8006B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2462; t=1190831601; x=1191695601; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ? |Sender:=20; bh=D2cqVLP67+yZ+RAs5d9kZnMNZBa15pqe9qWTPa3A7fo=; b=Wkjy5d0meOU3NIHxO+NDmyTjgEPOO6MXjrDYUn7Z0L0fY/NqOY3Escjm0fWFc1PhcFrSs5So lZHIlRouIyq9hmaq6/mGWP8luVcdUFcRKSRjFdQnJZrRRSApN0g4sVkA; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: tcpm@ietf.org, Tim Shepard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 >=20 >=20 > Anantha Ramaiah (ananth) wrote: > > Few points :- > >=20 > > - It is true that TCP secure recommendations might be=20 > useful for long=20 > > lived sessions like BGP. But there are many applications using TCP=20 > > which also could benefit from the proposed changes. >=20 > As an aside, it would be useful to provide in your doc an=20 > example of such an application, e.g., where the endpoints and=20 > port numbers are known or reasonably guessable. We can give it a thought about adding something if the WG feels so. I for one feel that we would want to preserve the generic nature of this document, you want to avoid listing application references as much as possible, we can give examples but as you it wouldn't be a complete list, anyways. >=20 > > The TCP secure changes > > needs to be viewed as a standalone thing, since it focusses in=20 > > providing robustness to TCP connections w.r.t some spoofing attacks. >=20 > The real point is that spoofing isn't a standalone thing.=20 > Putting protections into TCP without locking down ICMP isn't=20 > sufficient, and inferring authentication from header=20 > properties just narrows the window of attack. If we have to fix multiple layers, lets fix it, I have no problems. You can do all at once or piecemeal, as simple as that. It doesn't matter whether spoofing is standalone or not, it is about how well you can make your TCP stack respond to such malicious attacks, if you care to do so. >=20 > > - TCP secure, TCP MD5, TCP advanced security algorithms,=20 > IPsec are all=20 > > different tools with varying degrees of complexity and=20 > usage. A user=20 > > can chose to use one of them depending on his/her requirements.=20 > > Telling people to only use IPsec is akin to saying "always fly in=20 > > business class". Yes I have used this analogy before, but=20 > this is one=20 > > whih popped up in mind after today's coffee :-) >=20 > If we agree that users should be able to choose the solution=20 > that fits, let's go with MAYs all around. I know you want all MAY's in place. Some others (includes me) are not yet convinced that why SHOULD doesn't provide the same assurance. >=20 > Otherwise, aren't you dictating your solution as fitting=20 > everyone's needs? I am not "dictating" anything here. I am just supporting the reason why I feel it should be SHOULD's :-)=20 -Anantha >=20 > Joe >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 26 14:45:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iabsu-0001pe-VN; Wed, 26 Sep 2007 14:45:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iabss-0001Wg-Rq for tcpm@ietf.org; Wed, 26 Sep 2007 14:45:19 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iabsm-00043V-Dd for tcpm@ietf.org; Wed, 26 Sep 2007 14:45:18 -0400 Received: from [75.214.61.9] (9.sub-75-214-61.myvzw.com [75.214.61.9]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8QIijuh003273; Wed, 26 Sep 2007 11:44:46 -0700 (PDT) Message-ID: <46FAA88C.9040602@isi.edu> Date: Wed, 26 Sep 2007 11:44:28 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC5804052217@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5804052217@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: tcpm@ietf.org, Tim Shepard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0778149368==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0778149368== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig994089A26A0DA40D33CD4E90" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig994089A26A0DA40D33CD4E90 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: =2E.. > If we have to fix multiple layers, lets fix it, I have no problems. You= > can do all at once or piecemeal, as simple as that. It doesn't matter > whether spoofing is standalone or not, it is about how well you can mak= e > your TCP stack respond to such malicious attacks, if you care to do so.= TCP is not a secure protocol. It's not intended for protection from malicious attacks per se; 'fixing' it is to assert your solution on everyone, as below. >>> - TCP secure, TCP MD5, TCP advanced security algorithms,=20 >> IPsec are all=20 >>> different tools with varying degrees of complexity and=20 >> usage. A user=20 >>> can chose to use one of them depending on his/her requirements.=20 >>> Telling people to only use IPsec is akin to saying "always fly in=20 >>> business class". Yes I have used this analogy before, but=20 >> this is one=20 >>> whih popped up in mind after today's coffee :-) >> If we agree that users should be able to choose the solution=20 >> that fits, let's go with MAYs all around. >=20 > I know you want all MAY's in place. Some others (includes me) are not > yet convinced that why SHOULD doesn't provide the same assurance. >=20 >> Otherwise, aren't you dictating your solution as fitting=20 >> everyone's needs? >=20 > I am not "dictating" anything here. I am just supporting the reason why= > I feel it should be SHOULD's :-)=20 SHOULD dictates that everyone's TCP ought to have this included except for specific good reason. MAY allows them to make the choice themselves. Joe --------------enig994089A26A0DA40D33CD4E90 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 iD4DBQFG+qiWE5f5cImnZrsRAjylAJdHx2S53y6E44krHQRaLyZWnbZNAJ9TNsme OwAG838WxQOdb6ZydKNVQA== =wPB3 -----END PGP SIGNATURE----- --------------enig994089A26A0DA40D33CD4E90-- --===============0778149368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0778149368==-- From tcpm-bounces@ietf.org Wed Sep 26 14:59:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iac5N-0005SF-0e; Wed, 26 Sep 2007 14:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iac5L-0005Qc-FX for tcpm@ietf.org; Wed, 26 Sep 2007 14:58:11 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iac5E-0004Sc-DS for tcpm@ietf.org; Wed, 26 Sep 2007 14:58:11 -0400 X-IronPort-AV: E=Sophos;i="4.21,198,1188802800"; d="scan'208";a="402045786" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 26 Sep 2007 11:58:04 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8QIw3VB007853; Wed, 26 Sep 2007 11:58:03 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8QIvt7p002061; Wed, 26 Sep 2007 18:58:03 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); Wed, 26 Sep 2007 11:58:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Wed, 26 Sep 2007 11:58:02 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804052246@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <46FAA88C.9040602@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgAbVtc1evlqZRtSLqZNAqFF65wBwAAE4ng From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" X-OriginalArrivalTime: 26 Sep 2007 18:58:02.0807 (UTC) FILETIME=[2A1E7C70:01C8006F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1061; t=1190833083; x=1191697083; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ? |Sender:=20; bh=IoJWLPE1qN1weKqFsQHyHm4bPWhUqtC2j8cxJD8PF34=; b=WJ6WOSP/HFeUzud5mBAJ3EDlz3plMlinXNkHfkrJcIvi0mRCIRHLPhJPBG45QWGuKaxL4vb+ gHLOiFTklFWawo+a0SBhHpaTvTyRJdgvW+KtzGEvkAyDKXfmWpAcGMDa; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tcpm@ietf.org, Tim Shepard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org >=20 > Anantha Ramaiah (ananth) wrote: > ... > > If we have to fix multiple layers, lets fix it, I have no problems.=20 > > You can do all at once or piecemeal, as simple as that. It doesn't=20 > > matter whether spoofing is standalone or not, it is about=20 > how well you=20 > > can make your TCP stack respond to such malicious attacks,=20 > if you care to do so. >=20 > TCP is not a secure protocol. It's not intended for=20 > protection from malicious attacks per se; 'fixing' it is to=20 > assert your solution on everyone, as below. I see what you are saying except the "asserting your solution part".=20 But you seem to equating some efforts of making TCP more robust to TCP have an Ipsec like functionality, very far fetched, IMO. Hmm... It boils to your favorite line of thinking : "Don't make any robustness changes in TCP, just use IPsec", I thought we have beaten that to death long time ago. :-) Anyways, I don't want to side-track this discussion from it's original intent viz., "strength of mitigations" -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 26 15:29:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IacYs-0004DA-M6; Wed, 26 Sep 2007 15:28:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IacYr-0004BD-SO for tcpm@ietf.org; Wed, 26 Sep 2007 15:28:41 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IacYm-00060D-RC for tcpm@ietf.org; Wed, 26 Sep 2007 15:28:41 -0400 Received: from [75.214.61.9] (9.sub-75-214-61.myvzw.com [75.214.61.9]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8QJS2X8017024; Wed, 26 Sep 2007 12:28:02 -0700 (PDT) Message-ID: <46FAB2B9.60006@isi.edu> Date: Wed, 26 Sep 2007 12:27:53 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC5804052246@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5804052246@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tcpm@ietf.org, Tim Shepard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0748367709==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0748367709== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCC2EEDAD609F4DB12CF752B9" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCC2EEDAD609F4DB12CF752B9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: >> Anantha Ramaiah (ananth) wrote: >> ... >>> If we have to fix multiple layers, lets fix it, I have no problems.=20 >>> You can do all at once or piecemeal, as simple as that. It doesn't=20 >>> matter whether spoofing is standalone or not, it is about=20 >> how well you=20 >>> can make your TCP stack respond to such malicious attacks,=20 >> if you care to do so. >> >> TCP is not a secure protocol. It's not intended for=20 >> protection from malicious attacks per se; 'fixing' it is to=20 >> assert your solution on everyone, as below. >=20 > I see what you are saying except the "asserting your solution part".=20 =2E.. > Anyways, I don't want to side-track this discussion from it's original > intent viz., "strength of mitigations" OK, so let's get back to that. If you believe that it's appropriate to let people decide what mitigations they want to deploy, then why isn't tcpsecure a MAY? I.e., you MAY deploy it if you want the mitigations. There's no MUST in that logic, any more than 'you MUST deploy IPsec/BTNS/TCP-MD5++'. I think we're all agreeing that "let the user decide" is appropriate. What we disagree upon appears to be what that implies. Joe --------------enigCC2EEDAD609F4DB12CF752B9 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 iD8DBQFG+rK5E5f5cImnZrsRAi5RAKCRdvip2xRHhAJU3SF0EXbg9uWlPwCgzfEC /iiZhiw6c/H3EZZ99OOWxwc= =eFN1 -----END PGP SIGNATURE----- --------------enigCC2EEDAD609F4DB12CF752B9-- --===============0748367709== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0748367709==-- From tcpm-bounces@ietf.org Wed Sep 26 16:34:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IadZa-0004ox-RA; Wed, 26 Sep 2007 16:33:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IadZY-0004Xj-88 for tcpm@ietf.org; Wed, 26 Sep 2007 16:33:28 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IadZX-0006zT-Rp for tcpm@ietf.org; Wed, 26 Sep 2007 16:33:28 -0400 X-IronPort-AV: E=Sophos;i="4.21,199,1188802800"; d="scan'208";a="402083770" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 26 Sep 2007 13:33:27 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8QKXRVj026608; Wed, 26 Sep 2007 13:33:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8QKXM7h013874; Wed, 26 Sep 2007 20:33:27 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); Wed, 26 Sep 2007 13:33:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Wed, 26 Sep 2007 13:33:20 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804052330@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <46FAB2B9.60006@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgAc3JXLwwi70UsSIu1hxac0svtywABhTwQ From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" X-OriginalArrivalTime: 26 Sep 2007 20:33:22.0821 (UTC) FILETIME=[7B835B50:01C8007C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1685; t=1190838807; x=1191702807; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ? |Sender:=20; bh=hqlF5xepJAWg9Fyb8j0yxwfKntoiUS5jiuP0Z5b4dxg=; b=lpWjh2ndaa2WKwAx5E8BcY0M8L7DYBViEpcUzWM6oA6N2CExa8BrTHVaAZyrLOpyyNbEMQ9U XllmWjsRFNmmzM8Z2oStFC2R/wQYQwEsewbnELUSyAtzzAQlNaN4cFAv+4dzuSuZoj/P92gI+O AtTb4JUN9rXLs0fa0uLeWb558=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org, Tim Shepard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Inline comments.... > > Anyways, I don't want to side-track this discussion from=20 > it's original=20 > > intent viz., "strength of mitigations" >=20 > OK, so let's get back to that. If you believe that it's=20 > appropriate to let people decide what mitigations they want=20 > to deploy, then why isn't tcpsecure a MAY? Here is why I think it is SHOULD ( I have already pointed out the reasons, but will try to more explicit this time.) - I believe by making it a SHOULD it already lets people chose. Many implementations have ignored the recommendations tagged as SHOULD and some of them "knobbed" it for the "good reasons" of their own. - Like someone pointed out MAY is a weak statement, it could also imply "MAY not". Why should it be a MAY when we know that the pros of the soultion outweigh the cons? - to me these recommendations are good to have, so it falls under SHOULD since the internet has changed a lot from being what it was 20 years ago and I believe protocol robustness and quality are good to have and esp. for a pervasive protocol like TCP. To me "good to have" is a SHOULD. I agree it is not "MUST have". >=20 > I.e., you MAY deploy it if you want the mitigations. >=20 > There's no MUST in that logic, any more than 'you MUST deploy=20 > IPsec/BTNS/TCP-MD5++'. I am assuming it is a conditional MUST like "if you need security then use TCP MD5", correct? Is "conditional MUST =3D SHOULD" ? >=20 > I think we're all agreeing that "let the user decide" is appropriate. > What we disagree upon appears to be what that implies.=20 Yes I think we are all focussed on the RFC language to be used here. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 26 18:24:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IafFv-0007xc-CA; Wed, 26 Sep 2007 18:21:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IafFu-0007x4-1L for tcpm@ietf.org; Wed, 26 Sep 2007 18:21:18 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IafFo-0001Ua-HZ for tcpm@ietf.org; Wed, 26 Sep 2007 18:21:12 -0400 Received: from [75.214.61.9] (9.sub-75-214-61.myvzw.com [75.214.61.9]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8QMKFeX018523; Wed, 26 Sep 2007 15:20:16 -0700 (PDT) Message-ID: <46FADB17.2060008@isi.edu> Date: Wed, 26 Sep 2007 15:20:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC5804052330@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5804052330@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tcpm@ietf.org, Tim Shepard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0738282480==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0738282480== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig182A4C90BA8D90BF7A9FA0FF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig182A4C90BA8D90BF7A9FA0FF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > Inline comments.... =2E.. > - Like someone pointed out MAY is a weak statement, it could also imply= > "MAY not". Why should it be a MAY when we know that the pros of the > soultion outweigh the cons? They do not in all cases. If TCP is deployed either where no well-known connections exist, or where such connections are protected by other authentication, this solution adds a) complexity b) chatter during valid RSTs c) IPR encumberance > - to me these recommendations are good to have,=20 You're now making decisions for others, i.e., these recommendations are "good for everyone to have unless they have a reason not to". That's not what you said before in terms of "let the user/implementer decide". =2E.. >> There's no MUST in that logic, any more than 'you MUST deploy=20 >> IPsec/BTNS/TCP-MD5++'. >=20 > I am assuming it is a conditional MUST like "if you need security then > use TCP MD5", correct? Is "conditional MUST =3D SHOULD" ? It is a conditional SHOULD, i.e., a SHOULD with a caveat. From the RFC2119-level, IMO that's a MAY with explanation. Joe --------------enig182A4C90BA8D90BF7A9FA0FF 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 iD8DBQFG+tsXE5f5cImnZrsRAiVjAJ9zUu1STpLbMvf8MWZoh9YLnsMCIQCg6CUS QWRVEkWoyJQ/omH3jGgrBdY= =Ow3T -----END PGP SIGNATURE----- --------------enig182A4C90BA8D90BF7A9FA0FF-- --===============0738282480== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0738282480==-- From tcpm-bounces@ietf.org Wed Sep 26 19:32:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagK3-0004eI-VG; Wed, 26 Sep 2007 19:29:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagK3-0004dx-03 for tcpm@ietf.org; Wed, 26 Sep 2007 19:29:39 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IagJt-0003wn-Qn for tcpm@ietf.org; Wed, 26 Sep 2007 19:29:38 -0400 X-IronPort-AV: E=Sophos;i="4.21,199,1188802800"; d="scan'208";a="20248358" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Sep 2007 16:29:29 -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 l8QNTTwe011641; Wed, 26 Sep 2007 16:29:29 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8QNTTTo005462; Wed, 26 Sep 2007 23:29:29 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); Wed, 26 Sep 2007 16:29:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Wed, 26 Sep 2007 16:29:27 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580405246A@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <46FADB17.2060008@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgAjcUl981d9xFlQEyXg3fRKCbmNAABNo/g From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" X-OriginalArrivalTime: 26 Sep 2007 23:29:29.0068 (UTC) FILETIME=[157CB2C0:01C80095] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2086; t=1190849369; x=1191713369; 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]=20tcpsecure=3A=20how=20strong=20to=20recommend ? |Sender:=20; bh=l06Sji2u7e6eVlFCgr+WNzIyT7QOKyO0tztR6SarnMs=; b=mOJAEgNlIzoxq/9na/io4locOhkWeug+zBwOaR4b8Pfr9rLcR49edzYbjTdmiFRZcPcyvxKg kQIBGpsv0c0TVmfbhltp33bamA2lX5UMKk6VmF2tfqjpF02ZTBnYSy+x; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tcpm@ietf.org, Tim Shepard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > Anantha Ramaiah (ananth) wrote: > > Inline comments.... > ... > > - Like someone pointed out MAY is a weak statement, it could also=20 > > imply "MAY not". Why should it be a MAY when we know that=20 > the pros of=20 > > the soultion outweigh the cons? >=20 > They do not in all cases. If TCP is deployed either where no=20 > well-known connections exist, or where such connections are=20 > protected by other authentication, this solution adds > a) complexity "complexity" and the strength of mitigation cannot be tied together, IMO. Almost every solution that tries to add/modify/delete some TCP behaviour does add complexity to TCP processing. That said, we have already debated in the past, about the so called "complexity" of these solutions. > b) chatter during valid RSTs You mean an extra RTO? Ok, fair enough. But, benefits outweigh drawbacks, I would think. > c) IPR encumberance AFAIK, this is not an issue as this was beaten to death before. >=20 > > - to me these recommendations are good to have, >=20 > You're now making decisions for others, i.e., these=20 > recommendations are "good for everyone to have unless they=20 > have a reason not to". That's not what you said before in=20 > terms of "let the user/implementer decide". "Good to have" since it improves TCP robustness and quality, this is my viewpoint. This is different from "making decisions for others". >=20 > ... > >> There's no MUST in that logic, any more than 'you MUST deploy=20 > >> IPsec/BTNS/TCP-MD5++'. > >=20 > > I am assuming it is a conditional MUST like "if you need=20 > security then=20 > > use TCP MD5", correct? Is "conditional MUST =3D SHOULD" ? >=20 > It is a conditional SHOULD, i.e., a SHOULD with a caveat.=20 > From the RFC2119-level, IMO that's a MAY with explanation. Curious : Are you ok tagging the TCP secure mitigations with a "conditional SHOULD" or "SHOULD with caveat" or "an applicability statement with a SHOULD"? I am assuming that these are equivalent to MAY with explanation?=20 -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 26 19:57:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagkY-0000DP-HF; Wed, 26 Sep 2007 19:57:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagkX-0000DD-2U for tcpm@ietf.org; Wed, 26 Sep 2007 19:57:01 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IagkW-0003kv-KW for tcpm@ietf.org; Wed, 26 Sep 2007 19:57:00 -0400 Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8QNuWZm009857; Wed, 26 Sep 2007 16:56:32 -0700 (PDT) Message-ID: <46FAF1A8.3050600@isi.edu> Date: Wed, 26 Sep 2007 16:56:24 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC580405246A@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580405246A@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: tcpm@ietf.org, Tim Shepard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1878873360==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1878873360== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig733BBA6ABFC60CD88B5D9498" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig733BBA6ABFC60CD88B5D9498 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: =2E.. >> b) chatter during valid RSTs >=20 > You mean an extra RTO? Ok, fair enough. But, benefits outweigh > drawbacks, I would think. FWIW, I mean *responding* to a RST. >> c) IPR encumberance >=20 > AFAIK, this is not an issue as this was beaten to death before. It will remain the context under which a decision is made until IPR is removed. Each party weighing in needs to decide how that impacts their decision - and whether they want to impose it as a requirement on the community. >> ... >>>> There's no MUST in that logic, any more than 'you MUST deploy=20 >>>> IPsec/BTNS/TCP-MD5++'. >>> I am assuming it is a conditional MUST like "if you need=20 >> security then=20 >>> use TCP MD5", correct? Is "conditional MUST =3D SHOULD" ? >> It is a conditional SHOULD, i.e., a SHOULD with a caveat.=20 >> From the RFC2119-level, IMO that's a MAY with explanation. >=20 > Curious : Are you ok tagging the TCP secure mitigations with a > "conditional SHOULD" or "SHOULD with caveat" or "an applicability > statement with a SHOULD"? I am assuming that these are equivalent to MA= Y > with explanation?=20 I'm saying that MAY with explanation is sufficient. There's no point in a SHOULD unless you want to have the WG make a recommendation for others. Even with context, this still amounts to forcing a solution. If it's really all that useful and people aren't worried about the complexity or IPR, they'll implement it. Let them decide. Joe --------------enig733BBA6ABFC60CD88B5D9498 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 iD8DBQFG+vGpE5f5cImnZrsRAiuBAJ4sPd1iK87piBIiZOoJ4EaozZXnjwCgujLx LWIgLDzrtiNGWNZxD88QuZ8= =LeK1 -----END PGP SIGNATURE----- --------------enig733BBA6ABFC60CD88B5D9498-- --===============1878873360== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1878873360==-- From tcpm-bounces@ietf.org Thu Sep 27 01:11:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IalcR-0003ou-GW; Thu, 27 Sep 2007 01:08:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IalcP-0003YC-Fc for tcpm@ietf.org; Thu, 27 Sep 2007 01:08:57 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IalcP-0002L5-0S for tcpm@ietf.org; Thu, 27 Sep 2007 01:08:57 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l8R58I0K007090; Thu, 27 Sep 2007 08:08:18 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l8R58GmU007087; Thu, 27 Sep 2007 08:08:17 +0300 Date: Thu, 27 Sep 2007 08:08:16 +0300 (EEST) From: Pekka Savola To: Tim Shepard In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4411/Thu Sep 27 00:43:35 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi X-Spam-Score: -1.4 (-) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" , mallman@icir.org, Joe Touch Subject: [tcpm] BTNS usage for BGP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Tue, 25 Sep 2007, Tim Shepard wrote: ... > How's BTNS coming along? Will we be seeing BGP over BTNS anytime soon? > (I've not been following BTNS too closely recently). I wouldn't expect to see measurable deployment within the next, say, 5-10 years. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 27 01:13:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IalgI-0003FJ-Kw; Thu, 27 Sep 2007 01:12:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IalgG-0003CG-Q1 for tcpm@ietf.org; Thu, 27 Sep 2007 01:12:56 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IalgG-0002QF-BT for tcpm@ietf.org; Thu, 27 Sep 2007 01:12:56 -0400 Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8R5CTPu012186; Wed, 26 Sep 2007 22:12:29 -0700 (PDT) Message-ID: <46FB3BB6.5060704@isi.edu> Date: Wed, 26 Sep 2007 22:12:22 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pekka Savola References: In-Reply-To: X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" , Tim Shepard , mallman@icir.org Subject: [tcpm] Re: BTNS usage for BGP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1980791476==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1980791476== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5ED0D7E0D67316ED97BCD22F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5ED0D7E0D67316ED97BCD22F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Tue, 25 Sep 2007, Tim Shepard wrote: > ... >> How's BTNS coming along? Will we be seeing BGP over BTNS anytime soo= n? >> (I've not been following BTNS too closely recently). >=20 > I wouldn't expect to see measurable deployment within the next, say, > 5-10 years. It's not clear whether BTNS would be used for BGP per se; network managers may come to terms with the need for conventional IPsec and bite the CA bullet anyway. As to what will happen in 5-10 years, I'm not sure either, but I'll bet money against any specific prediction either way. I haven't seen one come true in 25 years. Joe --------------enig5ED0D7E0D67316ED97BCD22F 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 iD8DBQFG+zu2E5f5cImnZrsRAi0UAKCTLiDs/iq6S3AIBe+DW52R4XrJBwCg1dBF WQT45KFCKTd13UW3mt1CIw4= =v+XW -----END PGP SIGNATURE----- --------------enig5ED0D7E0D67316ED97BCD22F-- --===============1980791476== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1980791476==-- From tcpm-bounces@ietf.org Fri Sep 28 13:05:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJEx-0003UW-2b; Fri, 28 Sep 2007 13:02:59 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbJEw-0003UR-QK for tcpm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 13:02:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJEw-0003UJ-Fh for tcpm@ietf.org; Fri, 28 Sep 2007 13:02:58 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbJEw-0005d2-4d for tcpm@ietf.org; Fri, 28 Sep 2007 13:02:58 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8SH2upG025132; Fri, 28 Sep 2007 10:02:57 -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 43933FFE4C7; Fri, 28 Sep 2007 13:02:51 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 480052A9E95; Fri, 28 Sep 2007 13:01:42 -0400 (EDT) To: "Mitesh Dalal (mdalal)" From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <13D1EAB852BE194C94773A947138483D041D8B78@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Fri, 28 Sep 2007 13:01:42 -0400 Message-Id: <20070928170142.480052A9E95@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tcpm@ietf.org, Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0768906488==" Errors-To: tcpm-bounces@ietf.org --===============0768906488== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [catching up] > A point to note is that we neither obsolete nor update rfc793, so if we I think this is wrong. I think this document clearly updates 793. It says to do something differently from what 793 says and so I don't see how you can say it does not somehow update that document. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG/TN2WyrrWs4yIs4RArm6AJ42tGeUNB97zBHb4+XYvaMuZgQrCwCcDzRN VDjieve3Pka0dPFTD8rfB7g= =Xy3v -----END PGP SIGNATURE----- --=_bOundary-- --===============0768906488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0768906488==-- From tcpm-bounces@ietf.org Fri Sep 28 14:20:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKQO-0001vD-A0; Fri, 28 Sep 2007 14:18:52 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbKQM-0001v8-Q7 for tcpm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 14:18:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKQM-0001v0-Gc for tcpm@ietf.org; Fri, 28 Sep 2007 14:18:50 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbKQH-0000i6-55 for tcpm@ietf.org; Fri, 28 Sep 2007 14:18:50 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8SIIPUt026887; Fri, 28 Sep 2007 11:18:25 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id EC4F1FFF008; Fri, 28 Sep 2007 14:18:19 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 42E852A9F9F; Fri, 28 Sep 2007 14:17:11 -0400 (EDT) To: "Anantha Ramaiah (ananth)" From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <0C53DCFB700D144284A584F54711EC5804051D95@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Fri, 28 Sep 2007 14:17:11 -0400 Message-Id: <20070928181711.42E852A9F9F@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org, David Borman , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0571544286==" Errors-To: tcpm-bounces@ietf.org --===============0571544286== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Anantha- I have to say I am pretty drained from reading this thread and really don't know if we have consensus on anything or are driving towards developing it. The one thing that really confuses me in this discussion is the statements like this: > Since, all these discussions about started due to TCP secure, let me > use the same as an example. There is nothing wrong in making all > mitigations SHOULD since the "very good reason" can be one of :- It really seems to me that you are equating MAY and SHOULD. It seems like this is saying that implementers can come up with any reason to not implement tcpsecure if we tag these with a SHOULD. I think I understand a number of other people's distinctions between MAY and SHOULD, but I cannot figure out how you differentiate them and therefore I cannot figure out why you think they ought to be SHOULD and not MAY. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG/UUnWyrrWs4yIs4RAsa2AJ4wLn3GDG5/fl2t83QqBbvXUsLHdgCfceVv vBY2Dkz95Xn20iVULxyouyM= =Nq2T -----END PGP SIGNATURE----- --=_bOundary-- --===============0571544286== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0571544286==-- From tcpm-bounces@ietf.org Fri Sep 28 14:20:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKQ3-0001rv-GK; Fri, 28 Sep 2007 14:18:31 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbKQ2-0001oB-8X for tcpm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 14:18:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKQ1-0001o2-UJ for tcpm@ietf.org; Fri, 28 Sep 2007 14:18:29 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbKQ1-0008KQ-IV for tcpm@ietf.org; Fri, 28 Sep 2007 14:18:29 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8SIILhs026886; Fri, 28 Sep 2007 11:18:21 -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 E7154FFF007; Fri, 28 Sep 2007 14:18:15 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 245AB2A9F8D; Fri, 28 Sep 2007 14:17:07 -0400 (EDT) To: "Anantha Ramaiah (ananth)" From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <0C53DCFB700D144284A584F54711EC5804051D95@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Fri, 28 Sep 2007 14:17:07 -0400 Message-Id: <20070928181707.245AB2A9F8D@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tcpm@ietf.org, David Borman , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0861328810==" Errors-To: tcpm-bounces@ietf.org --===============0861328810== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline (Hat on. I just talked to Ted about this and he is in agreement with this request, but has not seen the text I am about to type ...) It seems to me that this discussion is really divergent because there is no applicability statement in the document, per Lars' comment. I wonder if you guys could go off and generate such a statement and then we could re-visit this question. I think that would factor things into a question of "where" this is applicable and then how strongly we want to advocate these mitigations within that context. Is that reasonable? Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG/UUiWyrrWs4yIs4RAvjxAJ9QjKw2XEu0sOy7H2ovjz2LPHRmbwCeJ6ns 4gdNctO2Q147g4ToPsHzgw4= =WbRp -----END PGP SIGNATURE----- --=_bOundary-- --===============0861328810== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0861328810==-- From tcpm-bounces@ietf.org Fri Sep 28 14:20:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKQO-0001vD-A0; Fri, 28 Sep 2007 14:18:52 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbKQM-0001v8-Q7 for tcpm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 14:18:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKQM-0001v0-Gc for tcpm@ietf.org; Fri, 28 Sep 2007 14:18:50 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbKQH-0000i6-55 for tcpm@ietf.org; Fri, 28 Sep 2007 14:18:50 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8SIIPUt026887; Fri, 28 Sep 2007 11:18:25 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id EC4F1FFF008; Fri, 28 Sep 2007 14:18:19 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 42E852A9F9F; Fri, 28 Sep 2007 14:17:11 -0400 (EDT) To: "Anantha Ramaiah (ananth)" From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <0C53DCFB700D144284A584F54711EC5804051D95@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Fri, 28 Sep 2007 14:17:11 -0400 Message-Id: <20070928181711.42E852A9F9F@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org, David Borman , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0571544286==" Errors-To: tcpm-bounces@ietf.org --===============0571544286== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Anantha- I have to say I am pretty drained from reading this thread and really don't know if we have consensus on anything or are driving towards developing it. The one thing that really confuses me in this discussion is the statements like this: > Since, all these discussions about started due to TCP secure, let me > use the same as an example. There is nothing wrong in making all > mitigations SHOULD since the "very good reason" can be one of :- It really seems to me that you are equating MAY and SHOULD. It seems like this is saying that implementers can come up with any reason to not implement tcpsecure if we tag these with a SHOULD. I think I understand a number of other people's distinctions between MAY and SHOULD, but I cannot figure out how you differentiate them and therefore I cannot figure out why you think they ought to be SHOULD and not MAY. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG/UUnWyrrWs4yIs4RAsa2AJ4wLn3GDG5/fl2t83QqBbvXUsLHdgCfceVv vBY2Dkz95Xn20iVULxyouyM= =Nq2T -----END PGP SIGNATURE----- --=_bOundary-- --===============0571544286== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0571544286==-- From tcpm-bounces@ietf.org Fri Sep 28 14:20:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKQ3-0001rv-GK; Fri, 28 Sep 2007 14:18:31 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbKQ2-0001oB-8X for tcpm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 14:18:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKQ1-0001o2-UJ for tcpm@ietf.org; Fri, 28 Sep 2007 14:18:29 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbKQ1-0008KQ-IV for tcpm@ietf.org; Fri, 28 Sep 2007 14:18:29 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8SIILhs026886; Fri, 28 Sep 2007 11:18:21 -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 E7154FFF007; Fri, 28 Sep 2007 14:18:15 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 245AB2A9F8D; Fri, 28 Sep 2007 14:17:07 -0400 (EDT) To: "Anantha Ramaiah (ananth)" From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <0C53DCFB700D144284A584F54711EC5804051D95@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Fri, 28 Sep 2007 14:17:07 -0400 Message-Id: <20070928181707.245AB2A9F8D@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tcpm@ietf.org, David Borman , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0861328810==" Errors-To: tcpm-bounces@ietf.org --===============0861328810== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline (Hat on. I just talked to Ted about this and he is in agreement with this request, but has not seen the text I am about to type ...) It seems to me that this discussion is really divergent because there is no applicability statement in the document, per Lars' comment. I wonder if you guys could go off and generate such a statement and then we could re-visit this question. I think that would factor things into a question of "where" this is applicable and then how strongly we want to advocate these mitigations within that context. Is that reasonable? Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG/UUiWyrrWs4yIs4RAvjxAJ9QjKw2XEu0sOy7H2ovjz2LPHRmbwCeJ6ns 4gdNctO2Q147g4ToPsHzgw4= =WbRp -----END PGP SIGNATURE----- --=_bOundary-- --===============0861328810== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0861328810==-- From tcpm-bounces@ietf.org Fri Sep 28 14:21:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKSa-0004TM-Ey; Fri, 28 Sep 2007 14:21:08 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbKSY-0004Q4-M8 for tcpm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 14:21:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKSY-0004Pw-By for tcpm@ietf.org; Fri, 28 Sep 2007 14:21:06 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbKSY-0008Np-0I for tcpm@ietf.org; Fri, 28 Sep 2007 14:21:06 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8SIKuAs026977; Fri, 28 Sep 2007 11:20:56 -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 AE3F6FFF00F; Fri, 28 Sep 2007 14:20:50 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id F23FD2A9FD5; Fri, 28 Sep 2007 14:19:41 -0400 (EDT) To: Tim Shepard From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Fri, 28 Sep 2007 14:19:41 -0400 Message-Id: <20070928181941.F23FD2A9FD5@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" , Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0780947631==" Errors-To: tcpm-bounces@ietf.org --===============0780947631== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > So I ask: is BTNS succeeding such that it is a viable alternative to > this tcpsecure draft? The way I view the world here, this question is not particularly germane. This WG has taken on a work item to produce tcpsecure. At some point perhaps there will be a larger cross-area/WG discussion of techniques to aid robustness in the face of spoofing and the IETF can then puzzle through what we like and what we do not. However, I don't think this WG is going to make those sorts of decisions. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG/UW9WyrrWs4yIs4RAkN7AJ99b+16Dhu/DXr3Yqk/sYn0WvVV4gCggNgd BY25f5eq8Naoyxj4RU7cRY4= =eII4 -----END PGP SIGNATURE----- --=_bOundary-- --===============0780947631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0780947631==-- From tcpm-bounces@ietf.org Fri Sep 28 14:52:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKvX-0005K1-Ef; Fri, 28 Sep 2007 14:51:03 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbKvV-0005F3-Cw for tcpm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 14:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKvU-0005DR-N8 for tcpm@ietf.org; Fri, 28 Sep 2007 14:51:00 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbKvT-0001Oo-GU for tcpm@ietf.org; Fri, 28 Sep 2007 14:51:00 -0400 X-IronPort-AV: E=Sophos;i="4.21,210,1188802800"; d="scan'208";a="529406946" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2007 11:50:59 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8SIowOc024896; Fri, 28 Sep 2007 11:50:58 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8SIoj1r001691; Fri, 28 Sep 2007 18:50:50 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); Fri, 28 Sep 2007 11:50:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Fri, 28 Sep 2007 11:50:44 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580409FB0B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20070928181707.245AB2A9F8D@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgB+/lsj99sURDqQRuUGXJVM6wmZAAAqKKQ From: "Anantha Ramaiah \(ananth\)" To: X-OriginalArrivalTime: 28 Sep 2007 18:50:46.0345 (UTC) FILETIME=[7ACB2B90:01C80200] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1410; t=1191005458; x=1191869458; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ?=20 |Sender:=20; bh=TzjKRQ4OHRVYRvOvz/cmoNbsnM8x794vliizLZUjAq4=; b=ONruL5p4007QC2qqwJKb1v/Rk/iJi3AwiOtK9lwdm02G8ClGAyS0od2petE5yBb6MRjlfklu XZG9DsVl8TVLf7iuWvUVN53wfxtAnJN77wDdF8Gnt03XlFp4Wi4F3Syr; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tcpm@ietf.org, David Borman , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > -----Original Message----- > From: mallman@icir.org [mailto:mallman@icir.org]=20 > Sent: Friday, September 28, 2007 11:17 AM > To: Anantha Ramaiah (ananth) > Cc: David Borman; Pekka Savola; tcpm@ietf.org; Fernando Gont > Subject: Re: [tcpm] tcpsecure: how strong to recommend?=20 >=20 >=20 > (Hat on. I just talked to Ted about this and he is in=20 > agreement with this request, but has not seen the text I am=20 > about to type ...) >=20 > It seems to me that this discussion is really divergent=20 > because there is no applicability statement in the document,=20 > per Lars' comment. I wonder if you guys could go off and=20 > generate such a statement and then we could re-visit this=20 > question. I think that would factor things into a question=20 > of "where" this is applicable and then how strongly we want=20 > to advocate these mitigations within that context. Is that=20 > reasonable? Well, if the applicability statement is needed for making some forward progress of the draft, then we need to do it.=20 Is there any particular format which we are looking at? Lars's email, if I remember correctly, also acknowledged the fact that not too many RFC's in the past have had these sort of applicability statements in place. So wondering any examples/ where to place one such ie., should it be a separate section like "Security considerations" ? -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 28 15:09:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLCM-0000np-G1; Fri, 28 Sep 2007 15:08:26 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbLCK-0000U7-QR for tcpm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 15:08:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLCK-0000QI-CU for tcpm@ietf.org; Fri, 28 Sep 2007 15:08:24 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbLCH-0001o2-Cj for tcpm@ietf.org; Fri, 28 Sep 2007 15:08:24 -0400 X-IronPort-AV: E=Sophos;i="4.21,210,1188802800"; d="scan'208";a="529416713" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2007 12:08:20 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8SJ8KY2012390; Fri, 28 Sep 2007 12:08:20 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8SJ8GDN015830; Fri, 28 Sep 2007 19:08:20 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); Fri, 28 Sep 2007 12:08:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Fri, 28 Sep 2007 12:08:08 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580409FB2B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20070928181711.42E852A9F9F@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgB/AEKuqonYB/3RRS96jK/enM7iAABND4A From: "Anantha Ramaiah \(ananth\)" To: X-OriginalArrivalTime: 28 Sep 2007 19:08:09.0452 (UTC) FILETIME=[E888AAC0:01C80202] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1942; t=1191006500; x=1191870500; 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]=20tcpsecure=3A=20how=20strong=20to=20recommend ?=20 |Sender:=20; bh=8ieKUkv55n9muxfqrhR4hPpFzyQoCOIznTZVgorL9QE=; b=qEsVN32ywjiIvA58gbcM0QGG2RMqqpRXztYSK3RCBEf2KMtKz3hW5U41xKCa9fVmrIWcKRHo dm9w0uXp+X1qgXo6VVDlCk+QWLkVfjDX0e/IMRHQaCEy96KizKJP0nVW; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tcpm@ietf.org, David Borman , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > -----Original Message----- > From: mallman@icir.org [mailto:mallman@icir.org]=20 > Sent: Friday, September 28, 2007 11:17 AM > To: Anantha Ramaiah (ananth) > Cc: David Borman; Pekka Savola; tcpm@ietf.org; Fernando Gont > Subject: Re: [tcpm] tcpsecure: how strong to recommend?=20 >=20 >=20 > Anantha- >=20 > I have to say I am pretty drained from reading this thread=20 > and really don't know if we have consensus on anything or are=20 > driving towards developing it. FWIW, the "majority vote" still stands at "2 SHOULDs and 1 MAY" ? So there is some consensus, it appears. >=20 > The one thing that really confuses me in this discussion is=20 > the statements like this: >=20 > > Since, all these discussions about started due to TCP=20 > secure, let me=20 > > use the same as an example. There is nothing wrong in making all=20 > > mitigations SHOULD since the "very good reason" can be one of :- >=20 > It really seems to me that you are equating MAY and SHOULD. =20 Sorry, I didn't mean to. > It seems like this is saying that implementers can come up=20 > with any reason to not implement tcpsecure if we tag these=20 > with a SHOULD. I think I understand a number of other=20 Yes, my thinking was always been : since it isn't a MUST, SHOULD gives that leeway. SHOULD gives the leeway that "you can chose not to implement if you have some good reasons". I had pointed out the list of reasons already. So are those reasons not "good enough" ? > people's distinctions between MAY and SHOULD, but I cannot=20 > figure out how you differentiate them and therefore I cannot=20 > figure out why you think they ought to be SHOULD and not MAY. My argument is simple, SHOULD gives a leeway and I think MAY is very weak. As somone pointed out MAY is equated to "MAY NOT" esp, when the recommendation is from a security viewpoint. -Anantha >=20 > allman >=20 >=20 >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 28 15:17:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLKy-00042q-Mr; Fri, 28 Sep 2007 15:17:20 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbLKw-00040w-NE for tcpm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 15:17:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLKw-00040l-CN for tcpm@ietf.org; Fri, 28 Sep 2007 15:17:18 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbLKv-0001E8-Ue for tcpm@ietf.org; Fri, 28 Sep 2007 15:17:18 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8SJHFwX028201; Fri, 28 Sep 2007 12:17:15 -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 3CA04FFF890; Fri, 28 Sep 2007 15:17:09 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B91972AA2DD; Fri, 28 Sep 2007 15:16:00 -0400 (EDT) To: "Anantha Ramaiah (ananth)" From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <0C53DCFB700D144284A584F54711EC580409FB0B@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Fri, 28 Sep 2007 15:16:00 -0400 Message-Id: <20070928191600.B91972AA2DD@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org, David Borman , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1938600008==" Errors-To: tcpm-bounces@ietf.org --===============1938600008== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Well, if the applicability statement is needed for making some forward > progress of the draft, then we need to do it. We are certainly open to suggestions from others on alternate ways to proceed. But, this seems like it will tease apart the issues so that maybe we can make some progress. > Is there any particular format which we are looking at? Lars's email, > if I remember correctly, also acknowledged the fact that not too many > RFC's in the past have had these sort of applicability statements in > place. So wondering any examples/ where to place one such ie., should > it be a separate section like "Security considerations" ? My advice is to find an example. I don't have one handy. But, do something reasonable so that the statement stands out. I.e., make it a (sub-)section or indent it under the words "applicability statement" or whatever. Just make sure we all know where it is without having to guess. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG/VLwWyrrWs4yIs4RAkuPAKCU1cliwR04p0x64/7MI+SbbMS6KQCgnfKv I5zXW/BahI6wfsp+XoBxang= =rqHy -----END PGP SIGNATURE----- --=_bOundary-- --===============1938600008== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1938600008==-- From tcpm-bounces@ietf.org Fri Sep 28 15:22:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLOq-0007BL-Qp; Fri, 28 Sep 2007 15:21:20 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbLOp-00079q-AC for tcpm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 15:21:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLOo-00079b-VO for tcpm@ietf.org; Fri, 28 Sep 2007 15:21:19 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbLOo-0001Mf-JD for tcpm@ietf.org; Fri, 28 Sep 2007 15:21:18 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8SJLFsH028275; Fri, 28 Sep 2007 12:21:15 -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 C28E5FFF8F6; Fri, 28 Sep 2007 15:21:09 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 4CE632AA30F; Fri, 28 Sep 2007 15:20:01 -0400 (EDT) To: "Anantha Ramaiah (ananth)" From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <0C53DCFB700D144284A584F54711EC580409FB2B@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Fri, 28 Sep 2007 15:20:01 -0400 Message-Id: <20070928192001.4CE632AA30F@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tcpm@ietf.org, David Borman , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1452938898==" Errors-To: tcpm-bounces@ietf.org --===============1452938898== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > I have to say I am pretty drained from reading this thread > > and really don't know if we have consensus on anything or are > > driving towards developing it. > > FWIW, the "majority vote" still stands at "2 SHOULDs and 1 MAY" ? So > there is some consensus, it appears. Well... we don't work on "majority vote". We work on consensus. Ted and I chatted a bit ago and I think it seems pretty clear to us that we have no consensus on this issue. 15 people 'voted' in the meeting and a few more people have voiced opinions on the list and even if one option is 'winning' it certainly isn't doing so with something we are comfortable calling even 'rough consensus' right now. People can of course argue that we're wrong. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG/VPhWyrrWs4yIs4RAsyQAJ9jR64qTvYmmsSYElZfDKY2dcIL8QCgh5Hk QX3e6q8FtPD8j0ZESZMS+94= =bfqU -----END PGP SIGNATURE----- --=_bOundary-- --===============1452938898== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1452938898==-- From tcpm-bounces@ietf.org Fri Sep 28 19:59:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbPgV-0008JM-0K; Fri, 28 Sep 2007 19:55:51 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbPgS-0008G2-S6 for tcpm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 19:55:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbPgS-0008Fu-HE for tcpm@ietf.org; Fri, 28 Sep 2007 19:55:48 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbPgS-0003G6-51 for tcpm@ietf.org; Fri, 28 Sep 2007 19:55:48 -0400 X-IronPort-AV: E=Sophos;i="4.21,211,1188802800"; d="scan'208";a="227326629" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 28 Sep 2007 16:55:47 -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 l8SNtlTD030837; Fri, 28 Sep 2007 16:55:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8SNtlDL011335; Fri, 28 Sep 2007 23:55:47 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 16:55:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Fri, 28 Sep 2007 16:55:42 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580409FCB3@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20070928192001.4CE632AA30F@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgCBMneMjsU6zfoS0OtLET4Dirt8wAIqJwg From: "Anantha Ramaiah \(ananth\)" To: X-OriginalArrivalTime: 28 Sep 2007 23:55:46.0949 (UTC) FILETIME=[16CDBB50:01C8022B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1296; t=1191023747; x=1191887747; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ?=20 |Sender:=20; bh=tVkRADVhy1HhNBk61xDSkDR/+lInfwSz1FLKxA/V3ZY=; b=cb+rvg37tDVHwO7mJVgDd6l6LOUdzi4BgoasENut6UUI53t0yGPYh4qZCfOQ1IdT38aRJ4FO RkX7xgjQEwLkLhz47BJJloMGALJQXkq0nYuxKYl3u4nJmEoSOWwdU9ZbV2TL4IX2la63clt5Rx 65fJsSMK6AieAfl0nQhpLimCQ=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tcpm@ietf.org, David Borman , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > > > I have to say I am pretty drained from reading this thread and=20 > > > really don't know if we have consensus on anything or are driving=20 > > > towards developing it. > >=20 > > FWIW, the "majority vote" still stands at "2 SHOULDs and 1=20 > MAY" ? So=20 > > there is some consensus, it appears. >=20 > Well... we don't work on "majority vote". We work on=20 > consensus. Ted and I chatted a bit ago and I think it seems=20 > pretty clear to us that we have no consensus on this issue. =20 > 15 people 'voted' in the meeting and a few more people have=20 > voiced opinions on the list and even if one option is=20 > 'winning' it certainly isn't doing so with something we are=20 > comfortable calling even 'rough consensus' right now. People=20 > can of course argue that we're wrong. In the last meeting in Chicago, it was pointed out the only pending issue is the "strength of the mitigations". 3 choices were listed, people picked the choices ( Careful not to use the "vote" since you don't seem to like it :-), So I would think the next step is to pick on whichever choice comes up as popular and move on. I for one don't see anything wrong with that approach. Atleast I am missing as to what would constitute a "rough consensus" ?=20 -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 28 20:26:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbQ8x-0003ca-37; Fri, 28 Sep 2007 20:25:15 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbQ8v-0003aZ-66 for tcpm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 20:25:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbQ8u-0003aR-RW for tcpm@ietf.org; Fri, 28 Sep 2007 20:25:12 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbQ8u-0003mc-Ci for tcpm@ietf.org; Fri, 28 Sep 2007 20:25:12 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8T0PBf0003682; Fri, 28 Sep 2007 17:25:11 -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 4786A1001762; Fri, 28 Sep 2007 20:25:05 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E84E02AA66C; Fri, 28 Sep 2007 20:23:53 -0400 (EDT) To: "Anantha Ramaiah (ananth)" From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <0C53DCFB700D144284A584F54711EC580409FCB3@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Fri, 28 Sep 2007 20:23:53 -0400 Message-Id: <20070929002353.E84E02AA66C@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1205230343==" Errors-To: tcpm-bounces@ietf.org --===============1205230343== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > In the last meeting in Chicago, it was pointed out the only pending > issue is the "strength of the mitigations". 3 choices were listed, > people picked the choices ( Careful not to use the "vote" since you > don't seem to like it :-), So I would think the next step is to pick > on whichever choice comes up as popular and move on. I for one don't > see anything wrong with that approach. > > Atleast I am missing as to what would constitute a "rough consensus" ? First, it isn't me that doesn't like the word "vote". It is the IETF that doesn't take "votes". Taking "votes" is problematic. Take a look at some of the IETF process documents, the Tao of the IETF, etc. These explain why there are not votes within the IETF and the rationale behind the consensus process. It seems to me that in this case it is clear that the WG is not generally of one mind (i.e., come to consensus), with a non-trivial number of folks wanting MAYs, SHOULDs and and/or some combination (via picking some MAYs and some SHOULDs or using conditionals or whatever). If you can show us that we're reading this wrong and that in fact these folks are outliers then please do. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG/ZsZWyrrWs4yIs4RAtecAJkBtkRL+/Xmg4CqDjg+juRROpBUmACgjvCI mFB/MQfVjZ+9crYD/+75GQw= =vM2E -----END PGP SIGNATURE----- --=_bOundary-- --===============1205230343== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1205230343==-- From tcpm-bounces@ietf.org Sat Sep 29 00:47:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbUBS-0005MJ-PW; Sat, 29 Sep 2007 00:44:06 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbUBR-0005MD-Ui for tcpm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 00:44:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbUBR-0005M5-Jw for tcpm@ietf.org; Sat, 29 Sep 2007 00:44:05 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbUBR-0007e9-7N for tcpm@ietf.org; Sat, 29 Sep 2007 00:44:05 -0400 X-IronPort-AV: E=Sophos;i="4.21,212,1188802800"; d="scan'208";a="178220005" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2007 21:44:04 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8T4i4sS000495; Fri, 28 Sep 2007 21:44:04 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8T4i41l022090; Sat, 29 Sep 2007 04:44:04 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); Fri, 28 Sep 2007 21:44:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Fri, 28 Sep 2007 21:44:01 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580409FCEF@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20070928191333.7E8172AA2AC@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgCA9i15X2PO7pqThW83ShJAZwoOgAKOK0g From: "Anantha Ramaiah \(ananth\)" To: X-OriginalArrivalTime: 29 Sep 2007 04:44:04.0352 (UTC) FILETIME=[5CDBF800:01C80253] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1946; t=1191041044; x=1191905044; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ?=20 |Sender:=20; bh=f2yyH90JYzllkE8n//5SefFBRTFev0vufdoPvyKhGeo=; b=bGku8CmG7/pmYtLciJPqnRZVi66gyScZPajDrxLl/srciEc+d6fcSmOjWx3m9+mrlx1pJAtg LOwd3d/yyifCgsrjGseToG2Dg6vbGLbAUQxfCQV06ugu8AL2eu7J6Tzn; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 >=20 > (FWIW, I still don't get it. If SHOULD gives the leeway not=20 > to do something for whatever reason you can come up with then=20 > how is it really different from MAY? I don't know .... I=20 > think there might be a distinction in your head, but I can't=20 > understand it.) Ok, I can try a brain dump :-) Per RFC 2119 Should is defined as : 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. So, the mitigations suggested in TCP secure is RECOMMENDED to have, but valid reasons like the ones which I pointed out may exist which can preclude it's implementation in a particular stack. Also implications of not adopting TCP secure is well understood since one may chose to "live" with less robustness. Also the general feeling is that post 9/11 security has increasingly becoming important in all walks of life, increasing robustness of a widely used protocol like TCP is not a bad idea, so making these mitigations a SHOULD is not a big deal, IMO. MAY is defined as : 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. Well if we view TCP secure as a optional thing, yes it makes sense to use MAY. I think TCP secure falls in a category above "optional" and below MUST and hence a SHOULD. Well, this is my thinking and I am not opposed to other's thinking, but saying that "SHOULD doesn't give leeway not to do something", is something which I would want to dis-agree. Hope I am clear. Again this is purely my opinion. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Sep 29 02:06:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbVQK-0007a2-7a; Sat, 29 Sep 2007 02:03:32 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbVQI-0007O3-Dz for tcpm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 02:03:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbVQH-000754-GV for tcpm@ietf.org; Sat, 29 Sep 2007 02:03:29 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbVQE-0000y7-Ul for tcpm@ietf.org; Sat, 29 Sep 2007 02:03:27 -0400 Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8T62ra8018919; Fri, 28 Sep 2007 23:02:53 -0700 (PDT) Message-ID: <46FDEA84.7040806@isi.edu> Date: Fri, 28 Sep 2007 23:02:44 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <20070929002353.E84E02AA66C@lawyers.icir.org> In-Reply-To: <20070929002353.E84E02AA66C@lawyers.icir.org> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1432137974==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1432137974== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5E7229D93BF2A7AD20681A11" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5E7229D93BF2A7AD20681A11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Allman wrote: >> In the last meeting in Chicago, it was pointed out the only pending >> issue is the "strength of the mitigations". 3 choices were listed, >> people picked the choices ( Careful not to use the "vote" since you >> don't seem to like it :-), So I would think the next step is to pick >> on whichever choice comes up as popular and move on. I for one don't >> see anything wrong with that approach. >> >> Atleast I am missing as to what would constitute a "rough consensus" ?= >=20 > First, it isn't me that doesn't like the word "vote". It is the IETF > that doesn't take "votes". Taking "votes" is problematic. Take a look= > at some of the IETF process documents, the Tao of the IETF, etc. These= > explain why there are not votes within the IETF and the rationale behin= d > the consensus process. >=20 > It seems to me that in this case it is clear that the WG is not > generally of one mind (i.e., come to consensus), with a non-trivial > number of folks wanting MAYs, SHOULDs and and/or some combination (via > picking some MAYs and some SHOULDs or using conditionals or whatever). > If you can show us that we're reading this wrong and that in fact these= > folks are outliers then please do. FWIW, there is a separate concern - current positions represent a very small set of participants. We are talking about modifications to 793 - whether MAY or SHOULD - and those should not be taken on the consensus of such a small sample as is currently weighing in. Joe --------------enig5E7229D93BF2A7AD20681A11 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 iD8DBQFG/eqFE5f5cImnZrsRAt6EAJ0Sd2eEntST4DMRVPg0myQCgdxHQQCglq2e Q3LlmVsQf825+lxQKzSCUuo= =OQak -----END PGP SIGNATURE----- --------------enig5E7229D93BF2A7AD20681A11-- --===============1432137974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1432137974==-- From tcpm-bounces@ietf.org Sat Sep 29 02:09:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbVW5-00073s-NY; Sat, 29 Sep 2007 02:09:29 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbVW4-00073n-8O for tcpm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 02:09:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbVW3-00073f-V5 for tcpm@ietf.org; Sat, 29 Sep 2007 02:09:27 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbVVx-0006qs-MN for tcpm@ietf.org; Sat, 29 Sep 2007 02:09:27 -0400 Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8T691jl020268; Fri, 28 Sep 2007 23:09:01 -0700 (PDT) Message-ID: <46FDEBF4.5010302@isi.edu> Date: Fri, 28 Sep 2007 23:08:52 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC580409FCEF@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580409FCEF@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1742974292==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1742974292== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA4892DFA5B0EDD69D0A66EE8" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA4892DFA5B0EDD69D0A66EE8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > =20 >> (FWIW, I still don't get it. If SHOULD gives the leeway not=20 >> to do something for whatever reason you can come up with then=20 >> how is it really different from MAY? I don't know .... I=20 >> think there might be a distinction in your head, but I can't=20 >> understand it.) >=20 > Ok, I can try a brain dump :-) >=20 > Per RFC 2119 >=20 > Should is defined as : >=20 > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. >=20 > So, the mitigations suggested in TCP secure is RECOMMENDED to have, but= > valid reasons like the ones which I pointed out may exist which can > preclude it's implementation in a particular stack. Also implications o= f > not adopting TCP secure is well understood since one may chose to "live= " > with less robustness. Also the general feeling is that post 9/11 > security has increasingly becoming important in all walks of life, > increasing robustness of a widely used protocol like TCP is not a bad > idea, so making these mitigations a SHOULD is not a big deal, IMO. First, SHOULD is a very big deal. SHOULD with IPR on a core Internet protocol is a huge deal. Second, security is increasingly a big deal everywhere. The bigger a deal it is, the more likely true authentication - in the form of either IPsec, TCP/MD5, or the latter's successors - would be the appropriate solution to protect Internet infrastructure. The more I hear about what this document intends and why it intends it, the less it sounds like a standards-track anything. Joe --------------enigA4892DFA5B0EDD69D0A66EE8 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 iD8DBQFG/ev0E5f5cImnZrsRAqgrAJ9evJRul5Gy7okomC4CO2fcB8eecgCg6D31 PmlhTPmi+tcyT2EjCApHdZ0= =wA77 -----END PGP SIGNATURE----- --------------enigA4892DFA5B0EDD69D0A66EE8-- --===============1742974292== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1742974292==-- From tcpm-bounces@ietf.org Sat Sep 29 13:39:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbgDi-0006mP-Qt; Sat, 29 Sep 2007 13:35:14 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbgDi-0006ln-0J for tcpm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 13:35:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbgDh-0006lf-Mx for tcpm@ietf.org; Sat, 29 Sep 2007 13:35:13 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbgDg-00046A-Gf for tcpm@ietf.org; Sat, 29 Sep 2007 13:35:13 -0400 X-IronPort-AV: E=Sophos;i="4.21,213,1188802800"; d="scan'208";a="227580220" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2007 10:35:12 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8THZBRU028368; Sat, 29 Sep 2007 10:35:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8THZ91l025372; Sat, 29 Sep 2007 17:35:09 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Sep 2007 10:35:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Sat, 29 Sep 2007 10:34:46 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580409FD14@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <46FDEBF4.5010302@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgCX0czKF+qN/mzQtq7+2jdZiwaSwAVXSFA From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" X-OriginalArrivalTime: 29 Sep 2007 17:35:08.0968 (UTC) FILETIME=[14B82280:01C802BF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=909; t=1191087311; x=1191951311; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ? |Sender:=20; bh=8XpI2q5o/ZOcGEwYcZY392EPADgO65hNuNzFoxLfcK8=; b=rGfVpSVvI7yGizYlIpdaGSh33g7fMQa69INK80G6GZW2+ScwkyXAXUTpOyyM+/ZmRb1gf+OV b7qOnUnUnMa+ONH/JY6pi0Kds0prvHEABwcvax3fLP1ZdY7PfWvj6/Of; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > Second, security is increasingly a big deal everywhere. The=20 > bigger a deal it is, the more likely true authentication - in=20 > the form of either IPsec, TCP/MD5, or the latter's successors=20 > - would be the appropriate solution to protect Internet=20 > infrastructure. TCP secure is about some modifications to make TCP robust in presense of some spoofed segments. TCP/MD5/Ipsec etc., are security solutions which are intended to protect TCP from a variety of cases. > The more I hear about what this document intends and why it=20 > intends it, the less it sounds like a standards-track anything. We are trying to focus on the strength of mitigations of the recommendations which is the last pending issue. I think we are digressing here from the original intent of this thread, Mark asked me why I believe these mitigations are SHOULD and I gave my opinion.=20 -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Sep 29 13:44:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbgMF-0000RC-RV; Sat, 29 Sep 2007 13:44:03 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbgMF-0000R7-9I for tcpm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 13:44:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbgME-0000Qz-VC for tcpm@ietf.org; Sat, 29 Sep 2007 13:44:02 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbgME-0003b6-HN for tcpm@ietf.org; Sat, 29 Sep 2007 13:44:02 -0400 Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8THhqio026914; Sat, 29 Sep 2007 10:43:52 -0700 (PDT) Message-ID: <46FE8ECA.2010503@isi.edu> Date: Sat, 29 Sep 2007 10:43:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC580409FD14@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580409FD14@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1704291092==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1704291092== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig930CB145EDFB340DEA4AB09B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig930CB145EDFB340DEA4AB09B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > =20 >> Second, security is increasingly a big deal everywhere. The=20 >> bigger a deal it is, the more likely true authentication - in=20 >> the form of either IPsec, TCP/MD5, or the latter's successors=20 >> - would be the appropriate solution to protect Internet=20 >> infrastructure. >=20 > TCP secure is about some modifications to make TCP robust in presense o= f > some spoofed segments. TCP/MD5/Ipsec etc., are security solutions which= > are intended to protect TCP from a variety of cases. TCP/MD5, and IPsec auth mode provide authentication. Authentication is to protect TCP from spoofing. TCPsecure protects against some spoofed TCP segments after a connection is established. TCP/MD5 and IPsec auth protect against all spoofed TCP segments througout a connection's lifetime. Fundamentally, though, all three protect against spoofing. That's what authentication is all about. Joe --------------enig930CB145EDFB340DEA4AB09B 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 iD8DBQFG/o7PE5f5cImnZrsRAqAvAJ40kvyxtjyLl5eAHZt22HkY3c1hoQCgmQWk pb/dSdRbE5wPheAf7kiZ3es= =W7xz -----END PGP SIGNATURE----- --------------enig930CB145EDFB340DEA4AB09B-- --===============1704291092== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1704291092==-- From tcpm-bounces@ietf.org Sat Sep 29 17:11:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbjYK-00027O-HW; Sat, 29 Sep 2007 17:08:44 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbjYK-00025p-1W for tcpm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 17:08:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbjYJ-000248-M4 for tcpm@ietf.org; Sat, 29 Sep 2007 17:08:43 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbjYJ-0007Gs-8U for tcpm@ietf.org; Sat, 29 Sep 2007 17:08:43 -0400 X-IronPort-AV: E=Sophos;i="4.21,213,1188802800"; d="scan'208";a="529686356" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 29 Sep 2007 14:08:42 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8TL8gUN023571; Sat, 29 Sep 2007 14:08:42 -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.12.10/8.12.6) with ESMTP id l8TL8e1l028366; Sat, 29 Sep 2007 21:08:40 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); Sat, 29 Sep 2007 14:08:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Sat, 29 Sep 2007 14:08:39 -0700 Message-ID: <13D1EAB852BE194C94773A947138483D04245252@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20070929002353.E84E02AA66C@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgCL/1y4YrB2kPNQ7+ZmL3sla2VygAq0XVA From: "Mitesh Dalal \(mdalal\)" To: , "Anantha Ramaiah \(ananth\)" X-OriginalArrivalTime: 29 Sep 2007 21:08:40.0337 (UTC) FILETIME=[E8E3E810:01C802DC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2396; t=1191100122; x=1191964122; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mdalal@cisco.com; z=From:=20=22Mitesh=20Dalal=20\(mdalal\)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ?=20 |Sender:=20; bh=B76hOTaD9ofQ3ulKr+a8Hs473xilLz6T/MSX8tXotiA=; b=psGt9H+kT8XYZxZs8M/DSQqa5yhxyIo5RrPMf0dDJSeJACkoomwWiH4Vr0qsDH2BsEDdGz3Q 4upCaY1DbAUjqOVmBwANTED1A0stcd73x+6PGTZCLQCTxGykTt1dph+P; Authentication-Results: sj-dkim-2; header.From=mdalal@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org FWIW, I think we need to address the fundamentals first, as echoed by Lars, Tim and your truly some time back. i.e. are we labeling this changes as updates to rfc793 ? Will we clearly state (if the document proceeds to standards track) to state "Updates: 793" in the title of the document ? OR are we looking it as an additional protocol that can be added/embedded to TCP (although there is no handshake to signal this understanding between the TCP peers to distinctly picture this as an option, but a small protocol nevertheless) and does not necessarily update the base spec ?=20 Once we hash this out, we can start the may/should/must nomenclature consensus drive. I may be the only voice that is unclear on this, but atleast we get to hear how folks perceive this. Mitesh > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org]=20 > Sent: Friday, September 28, 2007 5:24 PM > To: Anantha Ramaiah (ananth) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] tcpsecure: how strong to recommend?=20 >=20 >=20 > > In the last meeting in Chicago, it was pointed out the only pending=20 > > issue is the "strength of the mitigations". 3 choices were listed,=20 > > people picked the choices ( Careful not to use the "vote" since you=20 > > don't seem to like it :-), So I would think the next step=20 > is to pick=20 > > on whichever choice comes up as popular and move on. I for=20 > one don't=20 > > see anything wrong with that approach. > >=20 > > Atleast I am missing as to what would constitute a "rough=20 > consensus" ? >=20 > First, it isn't me that doesn't like the word "vote". It is=20 > the IETF that doesn't take "votes". Taking "votes" is=20 > problematic. Take a look at some of the IETF process=20 > documents, the Tao of the IETF, etc. These explain why there=20 > are not votes within the IETF and the rationale behind the=20 > consensus process. >=20 > It seems to me that in this case it is clear that the WG is=20 > not generally of one mind (i.e., come to consensus), with a=20 > non-trivial number of folks wanting MAYs, SHOULDs and and/or=20 > some combination (via picking some MAYs and some SHOULDs or=20 > using conditionals or whatever). > If you can show us that we're reading this wrong and that in=20 > fact these folks are outliers then please do. >=20 > allman >=20 >=20 >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Sep 29 17:21:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibjkf-0006Fc-1J; Sat, 29 Sep 2007 17:21:29 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ibjkd-00068J-Bg for tcpm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 17:21:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibjkd-00068B-2A for tcpm@ietf.org; Sat, 29 Sep 2007 17:21:27 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbjkW-00053J-PW for tcpm@ietf.org; Sat, 29 Sep 2007 17:21:27 -0400 Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8TLKkS6011555; Sat, 29 Sep 2007 14:20:46 -0700 (PDT) Message-ID: <46FEC1A5.5030003@isi.edu> Date: Sat, 29 Sep 2007 14:20:37 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Mitesh Dalal (mdalal)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <13D1EAB852BE194C94773A947138483D04245252@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <13D1EAB852BE194C94773A947138483D04245252@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.9 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0363869794==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0363869794== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig33EEC9C12B28F2FE90E7274B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig33EEC9C12B28F2FE90E7274B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mitesh Dalal (mdalal) wrote: > FWIW, I think we need to address the fundamentals first, as echoed by > Lars, Tim and your truly > some time back. i.e. are we labeling this changes as updates to rfc793 = ? > Will we clearly state > (if the document proceeds to standards track) to state "Updates: 793" > in the title of the document ? > OR >=20 > are we looking it as an additional protocol that can be added/embedded > to TCP (although there is no handshake to signal this understanding > between the TCP peers to distinctly picture this as an option, > but a small protocol nevertheless) and does not necessarily update the > base spec ?=20 Whether this is a small change or not is irrelevant to whether it updates TCP's rules for handling segments. All modifications to TCP segment processing events update 793 - whether they are standards track or experimental. An "additional protocol" could not change any TCP headers, TCP endpoint state, *or* TCP segment handling events. I remain confused at this sort of question coming up at all. If this is not a change to TCP, at the very least it is being discussed in the wrong working group. Joe >> -----Original Message----- >> From: Mark Allman [mailto:mallman@icir.org]=20 >> Sent: Friday, September 28, 2007 5:24 PM >> To: Anantha Ramaiah (ananth) >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] tcpsecure: how strong to recommend?=20 >> >> >>> In the last meeting in Chicago, it was pointed out the only pending=20 >>> issue is the "strength of the mitigations". 3 choices were listed,=20 >>> people picked the choices ( Careful not to use the "vote" since you=20 >>> don't seem to like it :-), So I would think the next step=20 >> is to pick=20 >>> on whichever choice comes up as popular and move on. I for=20 >> one don't=20 >>> see anything wrong with that approach. >>> >>> Atleast I am missing as to what would constitute a "rough=20 >> consensus" ? >> >> First, it isn't me that doesn't like the word "vote". It is=20 >> the IETF that doesn't take "votes". Taking "votes" is=20 >> problematic. Take a look at some of the IETF process=20 >> documents, the Tao of the IETF, etc. These explain why there=20 >> are not votes within the IETF and the rationale behind the=20 >> consensus process. >> >> It seems to me that in this case it is clear that the WG is=20 >> not generally of one mind (i.e., come to consensus), with a=20 >> non-trivial number of folks wanting MAYs, SHOULDs and and/or=20 >> some combination (via picking some MAYs and some SHOULDs or=20 >> using conditionals or whatever). >> If you can show us that we're reading this wrong and that in=20 >> fact these folks are outliers then please do. >> >> allman >> >> >> >> >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --------------enig33EEC9C12B28F2FE90E7274B 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 iD8DBQFG/sGmE5f5cImnZrsRAl0GAKDQR4h3aeRCxAAvQ4FROic4tzaT6wCffFYz 6c9emrue5NnN8sDRyW/GPVI= =dnDw -----END PGP SIGNATURE----- --------------enig33EEC9C12B28F2FE90E7274B-- --===============0363869794== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0363869794==-- From tcpm-bounces@ietf.org Sat Sep 29 21:04:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbnBX-0001Ut-H2; Sat, 29 Sep 2007 21:01:27 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbnBX-0001Uj-39 for tcpm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 21:01:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbnBW-0001Ua-Pm for tcpm@ietf.org; Sat, 29 Sep 2007 21:01:26 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbnBR-00046R-Et for tcpm@ietf.org; Sat, 29 Sep 2007 21:01:26 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8U11DBS000688; Sat, 29 Sep 2007 18:01:13 -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 A604A100A6EB; Sat, 29 Sep 2007 21:01:07 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A112B2AAE37; Sat, 29 Sep 2007 20:59:55 -0400 (EDT) To: "Mitesh Dalal (mdalal)" From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <13D1EAB852BE194C94773A947138483D04245252@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Sat, 29 Sep 2007 20:59:55 -0400 Message-Id: <20070930005955.A112B2AAE37@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1597472055==" Errors-To: tcpm-bounces@ietf.org --===============1597472055== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hat off ... personal opinion ... > i.e. are we labeling this changes as updates to rfc793 ? Will we > clearly state (if the document proceeds to standards track) to state > "Updates: 793" in the title of the document ? > > OR > > are we looking it as an additional protocol that can be added/embedded > to TCP (although there is no handshake to signal this understanding > between the TCP peers to distinctly picture this as an option, but a > small protocol nevertheless) and does not necessarily update the base > spec ? I cannot understand how this can be viewed as 'an additional protocol'. That seems nonsensical to me. To my way of thinking the mitigations in the tcpsecure document **change** the previously specified response to certain packets and therefore tcpsecure is necessarily an **update**. Maybe its just me ... allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG/vULWyrrWs4yIs4RAtkpAKCVDIf8mrEk3gFFepfk9hhRiz8KsACfVsT4 r44XH5OPwpQHE8Fgx766a4A= =kGAg -----END PGP SIGNATURE----- --=_bOundary-- --===============1597472055== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1597472055==-- From tcpm-bounces@ietf.org Sun Sep 30 02:17:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibs3a-0007DM-13; Sun, 30 Sep 2007 02:13:34 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ibs3Z-0007DH-2X for tcpm-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 02:13:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibs3Y-0007D9-L6 for tcpm@ietf.org; Sun, 30 Sep 2007 02:13:32 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ibs3Y-0000Wv-9p for tcpm@ietf.org; Sun, 30 Sep 2007 02:13:32 -0400 X-IronPort-AV: E=Sophos;i="4.21,213,1188802800"; d="scan'208";a="227717782" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2007 23:13:31 -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 l8U6DVUN014841; Sat, 29 Sep 2007 23:13:31 -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.12.10/8.12.6) with ESMTP id l8U6DS1l024745; Sun, 30 Sep 2007 06:13:29 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); Sat, 29 Sep 2007 23:13:28 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] tcpsecure: how strong to recommend? Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 29 Sep 2007 23:13:23 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <46FE8ECA.2010503@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgCwFVO1lal8FwxRHu6KjxLnr1/5AAZklBw From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 30 Sep 2007 06:13:28.0779 (UTC) FILETIME=[04B851B0:01C80329] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1195; t=1191132811; x=1191996811; 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]=20tcpsecure=3A=20how=20strong=20to=20recommend ? |Sender:=20; bh=tIRm0P6yYUHIrrXZZmGoLTTR4WoYswnPJhFtMShhCcQ=; b=d5Mvfzpwbqdszl23YKJPFZtbBrH+0Du3YKh02du7Hwi6fMDmMeGqQwTYd18a8axGFHk+rcSj zw6z7HojbBEgLtVW5qWKhxqywnZV4+suF94Sd0SrewTwCbZaMw82Tzp2; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > >=20 > > TCP secure is about some modifications to make TCP robust=20 > in presense=20 > > of some spoofed segments. TCP/MD5/Ipsec etc., are security=20 > solutions=20 > > which are intended to protect TCP from a variety of cases. >=20 > TCP/MD5, and IPsec auth mode provide authentication.=20 > Authentication is to protect TCP from spoofing. >=20 > TCPsecure protects against some spoofed TCP segments after a=20 > connection is established. >=20 > TCP/MD5 and IPsec auth protect against all spoofed TCP=20 > segments througout a connection's lifetime. >=20 > Fundamentally, though, all three protect against spoofing.=20 > That's what authentication is all about. I will have to dis-agree to this since my viewpoint is different. TCP secure adds robustness to the processing of certain TCP segments, which in turn helps to counter *some* spoofing attacks. Calling it as an authentication scheme seems too far-fetched. WHEREAS=20 TCP MD5, IPsec etc., are meant to be wholesome authentication schemes. Also this requires additional complexity in both software and hardware. Putting TCP secure and Ipsec in the same page beats me completely. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Sep 30 02:20:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibs9p-0003Km-2j; Sun, 30 Sep 2007 02:20:01 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ibs9o-0003Kc-4X for tcpm-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 02:20:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibs9n-0003J2-Ot for tcpm@ietf.org; Sun, 30 Sep 2007 02:19:59 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ibs9n-0000kB-B7 for tcpm@ietf.org; Sun, 30 Sep 2007 02:19:59 -0400 Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8U6Jdla003429; Sat, 29 Sep 2007 23:19:39 -0700 (PDT) Message-ID: <46FF3FFA.4080207@isi.edu> Date: Sat, 29 Sep 2007 23:19:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0476863089==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0476863089== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF99BA6DDA1CAE3108EAF6B0E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF99BA6DDA1CAE3108EAF6B0E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > =20 >>> TCP secure is about some modifications to make TCP robust=20 >> in presense=20 >>> of some spoofed segments. TCP/MD5/Ipsec etc., are security=20 >> solutions=20 >>> which are intended to protect TCP from a variety of cases. >> TCP/MD5, and IPsec auth mode provide authentication.=20 >> Authentication is to protect TCP from spoofing. >> >> TCPsecure protects against some spoofed TCP segments after a=20 >> connection is established. >> >> TCP/MD5 and IPsec auth protect against all spoofed TCP=20 >> segments througout a connection's lifetime. >> >> Fundamentally, though, all three protect against spoofing.=20 >> That's what authentication is all about. >=20 > I will have to dis-agree to this since my viewpoint is different. TCP > secure adds robustness to the processing of certain TCP segments, which= > in turn helps to counter *some* spoofing attacks. Calling it as an > authentication scheme seems too far-fetched. You are making an assertion about whether you believe the packet is spoofed or not based on its content matching what you expect from the true endpoint. That is called authentication. Weak, but still authentication. > WHEREAS=20 >=20 > TCP MD5, IPsec etc., are meant to be wholesome authentication schemes. > Also this requires additional complexity in both software and hardware.= In EITHER hardware or software. Neither one requires hardware. The level of additional complexity is commensurate with the level of protection they afford. Joe --------------enigF99BA6DDA1CAE3108EAF6B0E 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 iD8DBQFG/z/6E5f5cImnZrsRApFvAJ9bCnpIsh/vG3LldI9Qzq18505C+QCgvUPL l85fUSKU2oeBap1PCl2QNhk= =SS3F -----END PGP SIGNATURE----- --------------enigF99BA6DDA1CAE3108EAF6B0E-- --===============0476863089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0476863089==-- From tcpm-bounces@ietf.org Sun Sep 30 02:45:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbsYX-00032C-Ai; Sun, 30 Sep 2007 02:45:33 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbsYW-0002o8-01 for tcpm-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 02:45:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbsYQ-0001vZ-Ot for tcpm@ietf.org; Sun, 30 Sep 2007 02:45:26 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbsYQ-0001LS-F5 for tcpm@ietf.org; Sun, 30 Sep 2007 02:45:26 -0400 X-IronPort-AV: E=Sophos;i="4.21,213,1188802800"; d="scan'208";a="227725838" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2007 23:45:25 -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 l8U6jPuJ032169; Sat, 29 Sep 2007 23:45:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8U6jP1l010377; Sun, 30 Sep 2007 06:45:25 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Sep 2007 23:45:25 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [tcpm] tcpsecure: how strong to recommend? Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 29 Sep 2007 23:45:24 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580409FD54@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <46FF3FFA.4080207@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgDKfBc9XS9XmQmRLuz33b4HNhLjQAAFg4Q From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 30 Sep 2007 06:45:25.0525 (UTC) FILETIME=[7B308C50:01C8032D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1127; t=1191134725; x=1191998725; 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]=20tcpsecure=3A=20how=20strong=20to=20recommend ? |Sender:=20; bh=JahDW6EA0ub8MTDqp1vPcZNyDioECr0U0CIBHZaVOWw=; b=cGgmMesezHenSpG07rL7w1kByWRYeGeIlDlkWmM9zsy+vPK74oG9hoiFtxQiIaLq5X9ykkhi GP+wqvL/akaiSECMtxgZC0lG6fGMBAeCLtb0gNBq0Zyy2YajZLZwqmh9; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > > I will have to dis-agree to this since my viewpoint is=20 > different. TCP=20 > > secure adds robustness to the processing of certain TCP segments,=20 > > which in turn helps to counter *some* spoofing attacks.=20 > Calling it as=20 > > an authentication scheme seems too far-fetched. >=20 > You are making an assertion about whether you believe the=20 > packet is spoofed or not based on its content matching what=20 > you expect from the true endpoint. >=20 > That is called authentication. Weak, but still authentication. I am uncomfortable calling TCP secure as an authentication scheme. I would love to hear what others have to say on this. >=20 > > WHEREAS > >=20 > > TCP MD5, IPsec etc., are meant to be wholesome=20 > authentication schemes. > > Also this requires additional complexity in both software=20 > and hardware. >=20 > In EITHER hardware or software. Neither one requires=20 > hardware. The level of additional complexity is commensurate=20 > with the level of protection they afford. Agreed. Actually, I wanted to say "it may require hardware assist"=20 -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm