From tcpm-bounces@ietf.org Tue Nov 01 16:39:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX3r8-0004rR-VN; Tue, 01 Nov 2005 16:39:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX3r6-0004nc-FQ for tcpm@megatron.ietf.org; Tue, 01 Nov 2005 16:39:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17512 for ; Tue, 1 Nov 2005 16:39:23 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX45Y-0004TA-1J for tcpm@ietf.org; Tue, 01 Nov 2005 16:54:41 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id jA1LdRZi005622; Tue, 1 Nov 2005 13:39:27 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 761B377AAA8; Tue, 1 Nov 2005 16:39:25 -0500 (EST) To: Pasi Sarolahti From: Mark Allman Subject: Re: [tcpm] a different scheme for reacting to spurious RTOs In-Reply-To: <1126086947.29615.30.camel@siddha.research.nokia.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: It's Good to Be King MIME-Version: 1.0 Date: Tue, 01 Nov 2005 16:39:25 -0500 Message-Id: <20051101213925.761B377AAA8@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Ethan Blanton , tcpm@ietf.org, Josh Blanton 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="===============0448980399==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0448980399== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Pasi- I failed to reply to this note from long ago and apologize. > How about considering possibility of bounding K somehow, rather than > letting it increase indefinitely? Not until you asked. But, we have now. > While sometimes the blocked state can be really long, there also are > occasions where RTO is really needed to recover from a bursty data > loss, even with SACK in use ([1] is a nice paper describing observed > behavior in GPRS network). So if there happened to be an exceptionally > long delay spike, but also RTOs caused by packet losses, the total > performance (from the sender's perspective) could be worse with this > response than with TCP that does not detect spurious timeouts, even in > environment that has motivated much of the spurious RTO work. I don't > know what could be appropriate way to limit K: just a fixed, > configurable value, or by some adaptive method. I hope the current version of the draft addresses this point better. Basically, our feeling is that bounding K to some number is pointless. Say we put some bound B on K. Now, say we have a delay spike of 2*B and hence we'd use B as the value of K. What would that really do? Well, it would delay legitimate RTOs. But, it would not prevent spurious RTOs that we have observed. So, it's really quite unattractive all the way around. Rather than bounding K it seems that there could be a point whereby an implementation might just decide that K should not be changed. I.e., we don't want to make K = 2*B and making it K > 4 and < 2*B doesn't really solve anything. So, the answer there is not to change K at all. (Of course, if we see another delay spike that makes K > 4 and say 0.5*B then we could use 0.5*B to offer some protection. In other words, we have observed that while delay spikes are sometimes 2*B and the cost of mitigating these is too high, we have also seen smaller delay spikes that we are willing to mitigate.) Does this make sense? Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDZ+CNWyrrWs4yIs4RAnf0AJ47/sR3t8l71TM9hs5GM5BKas3cqgCfW1Pz yRu/OTrPeS+r/+TCgWfSrk4= =pPVy -----END PGP SIGNATURE----- --=_bOundary-- --===============0448980399== 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 --===============0448980399==-- From tcpm-bounces@ietf.org Wed Nov 02 17:43:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXRKg-0004AF-MI; Wed, 02 Nov 2005 17:43:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXRKe-00047f-KL for tcpm@megatron.ietf.org; Wed, 02 Nov 2005 17:43:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13035 for ; Wed, 2 Nov 2005 17:43:27 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXRZJ-0002dn-FN for tcpm@ietf.org; Wed, 02 Nov 2005 17:58:58 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA2Mg3M04909 for ; Wed, 2 Nov 2005 14:42:03 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jA2Mfsof010958 for tcpm@ietf.org; Wed, 2 Nov 2005 14:41:54 -0800 (PST) (envelope-from faber) Date: Wed, 2 Nov 2005 14:41:54 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20051102224154.GA10469@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.1i 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: 8b431ad66d60be2d47c7bfeb879db82c Subject: [tcpm] IETF 64 meeting 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="===============1462206870==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1462206870== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. Sorry for the late notice but your chairs and their computers have been up and down over the last week or so. The proposed agenda for the upcoming Vancouver meeting is available from http://tools.ietf.org/wg/tcpm/agenda (linked from http://www.isi.edu/tcpm/ as well). Links to the relevant IDs are included, so please do read up. And of course early discussions are fine. Omissions or errors to me and Mark, please. There is one big issue that hasn't really come up on the list that Mark and I would like to spend some time on while we've got you all in the room. Specifically we'd like to address whether or not there is still interest in trying to drive some of the existing specs forward from Proposed (or Experimental) up the Standards track. The charter as it stands indicates that we'd like to do this, but little has happened here. We'd like to come to some decisions on how important this activity is, and codify some new milestones based on that. Feel free to pipe up with ideas if you would like those aired before the meeting. --=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 --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDaUCyaUz3f+Zf+XsRAgKMAKCZP6Pm/k2WNW5uIflBx9tC6XPhxgCgqVy6 0PcIFuin4wK9N296ygArzAQ= =OseK -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- --===============1462206870== 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 --===============1462206870==-- From tcpm-bounces@ietf.org Sat Nov 05 22:00:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYamA-0002ji-Ek; Sat, 05 Nov 2005 22:00:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYam9-0002jd-82 for tcpm@megatron.ietf.org; Sat, 05 Nov 2005 22:00:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04833 for ; Sat, 5 Nov 2005 22:00:33 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYb1S-0002eI-W7 for tcpm@ietf.org; Sat, 05 Nov 2005 22:16:47 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA630lU18086 for ; Sun, 6 Nov 2005 05:00:47 +0200 Date: Sun, 6 Nov 2005 05:00:47 +0200 (EET) From: Pekka Savola To: tcpm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Subject: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org It may be needless to say this, but in any case.. I re-read draft-gont-tcpm-icmp-attacks-05 on the plane. The last rev I had read properly was probably -02 or -03. I was very pleased with this version; I was much more skeptic of certain parts of the doc (e.g., PMTUD attacks) before, but I think the document is well written and convincing now. I'd recommend adopting this as a WG item (provided that Fernando would then lift the "no derivative works" clause, because otherwise the doc can't be used in the IETF process). This could be any of Informational, Experimental, Proposed Standard or BCP. Anything works for me, but maybe it'd be better to start with either of the first two and revisit after a couple of years and more experience. minor issues ------------ 1) Wasn't (quite the obvious) sequence number randomization mentioned as a subsection under 4.x at some point in the past? I think it should be briefly mentioned here, because even if it's obvious, I don't recall it has been clearly documented as a security measure. 2) in below, I think you forgot to underline that the below treatment only applies for sockets in synchronized states? Therefore, TCP SHOULD treat all of the above messages as indicating "soft errors", rather than "hard errors", and thus SHOULD NOT abort the corresponding connection upon receipt of them. 3) While I agree with the conclusion of section 5.2.2., I think the justification does not hold. Let's consider the cases systematically: 1) hard error is spoofed, connection is progressing 2) hard error is legitimate, connection is stalled a) hard errors are converted to soft errors (and ignored and/or brought up to the application) b) hard errors are ignored until N retransmits have proved unsuccesful, then b.1) converted to soft errors, or b.2) connection is aborted. a) + 1) and b) + 1) are pretty close to equivalent (unless the application aborts the session without better knowledge that this is an attack). However, a) + 2) and b.2) + 2) are slightly different: some might view it as *desirable* to abort the session sooner if there is legitimate reason to believe that the error was genuinine -- rather than having to wait for minutes for it to die out on its own. However, as I said, I think I agree with your main point that just doing a) is simpler and the benefit of b) compared to it in the legitimate case may not be worth the additional 10 lines of code. 5.2.2. Delaying the connection-reset An alternative counter-measure could be to delay the connection reset. Rather than immediately aborting a connection, a TCP would abort a connection only after an ICMP error message indicating a hard error has been received, and the corresponding data have already been retransmitted more than some specified number of times. The rationale behind this proposed fix is that if a host can make forward progress on a connection, it can completely disregard the "hard errors" being indicated by the received ICMP error messages. While this counter-measure could be useful, we think that the counter-measure discussed in Section 5.2.1 is easier to implement, and provides increased protection against this type of attack. editorial --------- The affected systems ranged from TCP/IP implementations meant for desktop computers, to TCP/IP implementations meant for core Internet routers. ==> "," is unnecessary. The Internet Control Message Protocol (ICMP) is used in the Internet Architecture mainly to perform the fault-isolation function, that is, the group of actions that hosts and routers take to determine that there is some network failure [RFC0816] ==> missing "." at the end. Additional considerations for the validation of ICMP error messages can be found in Appendix C ==> ditto. When TCP is handled an ICMP error message, it will perform its fault recovery function, as follows: ==> s/handled/handed/ (or something a bit better) Those systems that do not implement the PMTUD mechanism should not be sending their IP packets with the DF bit set, and thus should not be receiving these ICMP error messages. Thus, it would be fair for them to treat this ICMP error message as indicating a soft error, therefore not aborting the corresponding connection when such an error message is received. On the other hand, and for obvious reasons, those systems implementing the Path-MTU Discovery (PMTUD) mechanism [RFC1191] should not abort the corresponding connection when such an ICMP error message is received. ==> I'd change the order here: describe PMTUD-enabled systems first because they're a majority. ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF ==> s/neeed/needed/ ICMP "Destination Unreachable, fragmentation needed and DF set" packet (or their ICMPv6 counterpart) to the sending host, advertising ==> s/their/the/ or "its" (the're just one ICMP type you're talking about) results. Another posible scenario is that in which a TCP connection is being secured by means of IPSec. If the Next-Hop MTU reported by ==> s/posible/possible/ ==> s/by means of/using/ If this check is passed, claimedmtu should be compared with ==> s/is passed/passes/ ? EVENT: Segment is sent if (packet_size > maxsizesent) maxsizesent = packet_size; ==> logically the code might read a bit easier (at least to me) if this read: EVENT: Segment is sent if (maxsizesent < packet_size) maxsizesent = packet_size; .. but this probably isn't worth changing. -- 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 Sat Nov 05 22:06:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYarG-0004Im-KL; Sat, 05 Nov 2005 22:06:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYarE-0004Gt-L6 for tcpm@megatron.ietf.org; Sat, 05 Nov 2005 22:06:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05108 for ; Sat, 5 Nov 2005 22:05:48 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYb6X-0002nC-Fp for tcpm@ietf.org; Sat, 05 Nov 2005 22:22:03 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA6361L18218 for ; Sun, 6 Nov 2005 05:06:01 +0200 Date: Sun, 6 Nov 2005 05:06:00 +0200 (EET) From: Pekka Savola To: tcpm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [tcpm] comments on draft-gont-tcpm-tcp-soft-errors-02 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org It may be needless to say this, as my stance should be pretty obvious, but.. I re-read draft-gont-tcpm-tcp-soft-errors-02.txt on the plane and IMHO it's ready to be adopted as WG item for Informational, and even WG last called very soon afterwards. I think the text is very convincing as a whole. Appendix A.1 could have been even more clear that the "more conservative approach" doesn't really fix the problem, as reducing the timeout from 3 minutes to (say) 75 seconds doesn't help at all. If the timeout is more than 5-10 seconds, it's too long (and I'd say even 5-10 secs per address is too long but may be on the borderline of a bearable user experience). editorial --------- Additionaly, it describes a modification to TCP's reaction to soft ... Additionaly, it documents a modification to TCP's policy of reaction ==> s/naly/nally/ In case a host does receive an ICMP error message meant for an ongoing TCP connection, the IP layer will pass this message up to ==> s/meant for/related to/ ? [6] Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 (work in progress), July 2004. ==> please put this as an informative reference, as the current status of the document is uncertain; it's not 100% clear if it's going to be published or not and on which time scale if so. -- 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 Sun Nov 06 13:01:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYope-0004Jj-Nf; Sun, 06 Nov 2005 13:01:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYopb-0004Jb-9B for tcpm@megatron.ietf.org; Sun, 06 Nov 2005 13:01:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11948 for ; Sun, 6 Nov 2005 13:01:01 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYp52-0000bn-FL for tcpm@ietf.org; Sun, 06 Nov 2005 13:17:25 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA6I1Ew02797 for ; Sun, 6 Nov 2005 20:01:14 +0200 Date: Sun, 6 Nov 2005 20:01:14 +0200 (EET) From: Pekka Savola To: tcpm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Subject: [tcpm] comments on draft-ietf-tcpm-tcp-antispoof-02 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org My comments below. There are still some things to fix, but most of the below should be straightforward. substantial ----------- 1) the receiver buffer sizing assumption does not seem realistic in sufficiently many cases so that I think it should not be made. 3. the advertised receive window is a large fraction of the overall maximum receive window size, e.g., because the receive socket buffers are set to match a large bandwidth-delay product [...] Of these assumptions, the last two are more notable. The issue of receive socket buffers was discussed in Sec. 2. [....] ==> the receive buffer assumption rattled me a bit, especially in the context of BGP. I think it's very common, especially when talking about routers, that a single application does not expect to use all the bandwidth of the link. It usually even can't: the route processors are busy with other stuff, and might be very slow. A BGP session which would fly at the rate of (even) 100 Mbit/s would be a surprise to me. I just checked; Cisco has by default around 4 KB for BGP (for others, 32KB), and it isn't even possible to config it up to more than 128K. Juniper has by default 16KB, and AFAICS there is no way to configure it. Given that the document talks so much of the specific case of BGP sessions, it seems that the document shouldn't just go ahead with an assumption that's known to be wrong in that (and many other cases). I don't think changes the main thrust of the document, though: attacking the sessions would still be achievable in the order of seconds or a minute. Maybe what needs to be done is calculate two tables: one where the buffers are adjusted so that the bandwidth can be used in a maximum manner and where the buffers are capped at (say) 16, 32 or 64 kB. That would give realistic calculations in either case without having to make assumptions about the buffers. (This same is in the first sentence of section 3.1.5.) 2) I think the address filtering (section 3.2.1) is still a bit lacking. Its main problems are: a) "It cannot restrict traffic from the core to the edges" -- but it can, assuming you mean an independent leaf-site with "edge" here. Specifically, all sites should and must perform filtering of their own, to discard any packets which come with their own source address from the direction of the Internet. This eliminates spoofing attacks from outside of the border. (This seems to be correctly reflected in the subsequent text, so maybe I just didn't understand what you meant with the above statement.) b) TTL checking problem with tunnels is still inaccurate. Tunnel is like any other (physical interface). If you get packets from an interface that are directed at you, the TTL is not decremented; if you forward those packets on some other interface, the TTL is decremented. Therefore the case where the TTL checking would be too unreliable is the same whether the neighbor peer has virtual or physical interfaces: if your peer doesn't behave properly (decrement the TTL), it's de-facto masquerading as someone else. The TTL check specifically assumes that you are able to trust your peer not to rewrite or create bogus packets, there is very little tunneling-specific about this as far as I can see. c) At the beginning of section 3.2, you say "filtering is an indirect system which relies on other parties to filter packets ..." which is correct in the general case but not when examining the sessions inside a border (where you can _yourself_ do the filtering, without relying on anyone else). This distinction is important depending on what kind of sessions you're interested in protecting and how large area your borders cover. ... In order to try to converge on the text faster, let me try to suggest text which I think should be more accurate and I'd find acceptable. ================ 3.2. Network Layer (IP) Solutions There are two primary variants of network layer solutions to spoofing: address filtering and IPsec. Address filtering provides protection from spoofing for sessions which are internal to the set of domains where address filtering is applied. IPsec requires cooperation between the endpoints wanting to avoid attack on their connection, which currently involves pre-existing shared knowledge of either a shared key or shared certificate authority. 3.2.1. Address and TTL filtering Address filtering is often proposed as an alternative to protocol mechanisms to defeat IP source address spoofing [2][12]. Address filtering is deployed both at the downstream interfaces and at the upstream/peer interfaces. The former prevents all spoofing from the downstream direction; the latter prevents only upstream sources from spoofing your (or your downstreams') source addresses. Each border router should perform the appropriate filtering for overall protection to result; failure of any border router to filter opens a hole inside that border. Address filtering at the border can protect those inside it from some kinds of spoofing, because only interior addresses should originate inside the border. It cannot, however, protect connections originating outside the border except to restrict where the traffic enters from, e.g., if it expected from one AS and not another. As a result, address filtering can be deployed locally but it only protects communications where both parties are local. Therefore, the larger the address filtering border is, the more extensive the protection is. This is a particularly useful means of protection for specific kinds of sessions which are known to be local. However, as address filtering is performed in the network by trusted gateways, the users not know whether the filtering exists or not. Hence, the users cannot rely on it in general and other mechanisms for protection must be used as well. Still, address filtering is very useful to protect specific kinds of communications (e.g., network management, most router-to-router communication, etc.). A more recent variant of address filtering checks the IP TTL field, relying on the TTL set by the other end of the connection [14]. This technique has been used to provide filtering for BGP. It assumes the connection source TTL is set to 255; packets at the receiver are checked for TTL=255, and others are dropped. This restricts traffic to one hop upstream of the receiver (i.e., a BGP router), but those hops could include other user programs at those nodes (e.g., the BGP router's peer). This method of filtering works best where traffic originates one hop away, so that the address filtering is based on the trust of only directly-connected (tunneled or otherwise) nodes. Like conventional address filtering, this light-weight mechanism reduces spoofing traffic in general and provides a reliable security mechanism if peer can be trusted to operate correctly (see Section 5.1 of [14]). On the other hand, if the peer does not operate correctly, it is just shooting itself in the foot by allowing its sessios to be reset. ================ .............. 3) the processing complexity comparison between transport vs network solutions seems assumptive. [issues why transport layer solution is not good] Finally, because the authentication happens later in packet processing than is required, additional endpoint resources may be needlessly consumed, e.g., in demultiplexing received packets, indexing connection identifiers, etc., only to be dropped later at the transport layer. and: A network layer solution avoids the hazards of multiple transport variants, using a single shared endpoint authentication mechanism early in receiver packet processing to discard unauthenticated packets at the network layer instead. ==> a reality check might be useful here. What is computationally more expensive -- demuxing and checking the transport control packets or doing IPsec processing and decryption (and dropping a packet when it fails the IPsec transform)? Unless you have IPsec hardware, the answer should be pretty obvious... (obviously, the address filtering mechanisms are still computationally more lightweight than either of these.) 4) network layer solution may not be able to cope with on-path ICMP. Finally, a network layer solution protects not only the transport layer but the network layer as well, e.g., from ICMP, IGMP, etc., spoofing attacks. ==> this appears to be too simplistic a statement. You are probably assuming that ICMP errors from the path can be safely ignored. If they can't, network mechanisms like IPsec cannot in practice cope with this kind of packets because setting up SAs to all the middleboxes is not feasible. 5) BTNS applicability is slightly too simplistic Alternative mechanisms are under development to address this limitation, to allow publicly-accessible servers to secure connections to clients not known in advance, or to allow unilateral relaxation of identity validation so that the remaining protections of IPsec to be available [38][39]. In particular, these mechanisms can prevent a client (but without knowing who that client is) from being affected by spoofing from other clients, even when the attackers are on the communications path. ==> AFAICS, "are on the communications path" is assumptive or simplistic. Either you must have a previously established relation (which you know is MITM-free) to a peer, or you meant something like "would later, after establishing the session, get on the communications path". After all, BTNS does not protect from MITM if the MITM was there when the session was set up and you don't have prior knowledge of the peer. 6) The description why IPsec is not used to protect router-to-router communications fails to address the added IPsec processing requirements, which are typically prohibitive. IPsec, although widely available both in commercial routers and commodity end-systems, is not often utilized except between parties that already have a preexisting relationship (employee/employer, between two ISPs, etc.) Servers to anonymous clients (e.g., customer/ business) or more open services (e.g., BGP, where routers may have large numbers of peers) are unmanageable, due to the breadth and flux of CAs. [...] ==> This is too simplistic description of why IPsec isn't used between routers. While management of certificates is a major issue, at least as important for me as an operator are the processing requirements of IPsec. If you don't have dedicated hardware for the task, I'd rather spend the routing engine's CPU cycles on processing the BGP update packets (and other control data) rather than encryption, decryption, hashing, etc. Let me say this clearly: BTNS/Anonsec will not be used by routers unless they have dedicated IPsec hardware (and the vast majority of them won't in the short term at least). (Hopefully this will be appropriately reflected in the BTNS problem statement as well.) 7) not sure if I agree with conclusions because we haven't yet reached consensus on the body yet (this is a placeholder :) The security of various levels of the protocol stack is addressed. Spoofing attacks are fundamentally identity masquerading, so we believe the most appropriate solutions defeat these at the network layer, where end-to-end identity lies. Some transport protocols subsume endpoint identity information from the network layer (e.g., TCP pseudo-headers), whereas others establish per-connection identity based on exchanged nonces (e.g., SCTP). It is reasonable, if not recommended, to address security at all layers of the protocol stack. ==> not sure if I completely agree with these conclusions here (and in section 5), but when/if we get to agreement on the main body of the doc, it should be easier to get to consensus on the recommendations as well. editorial --------- This, coupled with the lack of sufficient address filtering to drop such spoofed traffic, can increase the potential for off-path third- party spoofing attacks. ==> you include refs later in the doc for this, so maybe they should be here as well. [...] even when not fixed, there are only 65,384 valid source ports which may be exhaustively attacked. ==> how do you get that specific number? Why this isn't 2^16 ? protocol, although emerging as standard practice, unnecessarily complicates the design and implementation of new protocols [28] As new attacks are discovered (SYN floods, RSTs, etc.), each protocol ==> missing a period here. In addition, many networks filter all ICMP packets because validation may not be possible, especially because they can be injected from any point on a path, and so cannot be selectively address filtered. ==> actually, the problem with ICMP is that they can be injected from any point *at all*, not just restricted to the path, and regular address filtering doesn't help there (whereas address filtering could help with TCP RSTs in some cases). Network solutions are computationally intensive and require pervasive registration of certificate authorities with every possible endpoint. This section explains these observations further. ==> after the addition of address filtering in section 3.2, this needs to be updated to refer to just the ipsec part of network solutions. 4. the entire body of the packet is secured 5. security associations are established only where identity is authenticated by a know certificate authority or other pre-shared key 6. both on-path and off-path third-party spoofing attacks must be defeated ==> these should be numbered from 1 to 3, as you're referring to (1) and (2) in the text below... [2] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks," RFC 2827 / BCP 84, March 2004. [12] Ferguson, P. and D. Senie, Network Ingress Ingress Filt Defeating Denial of Service Attacks which employ IP Add Spoofing," RFC 2267 / BCP 38, May 2000. ==> BCP 84 is RFC 3704 while BCP 38 is 2827; earlier version of BCP 38 was 2267. [38] Touch, J., "ANONsec: Anonymous Security to Defend Again Spoofing Attacks," draft-touch-anonsec-00 (work in prog May 2004. [5] Better Than Nothing Security [BTNS] BOF, IETF-61, Wash. DC., http://www.ietf.org/ietf/04nov/btns.txt ==> these (and the text where they're referred to) have since been somewhat obsoleted. Maybe it would be sufficient to refer to the latest BTNS WG docs and/or the BTNS charter? -- 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 Sun Nov 06 13:27:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYpEs-0002L8-8A; Sun, 06 Nov 2005 13:27:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYpEr-0002Jk-7s for tcpm@megatron.ietf.org; Sun, 06 Nov 2005 13:27:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13195 for ; Sun, 6 Nov 2005 13:27:07 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYpUJ-0001Ct-6P for tcpm@ietf.org; Sun, 06 Nov 2005 13:43:31 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA6IRFO03398; Sun, 6 Nov 2005 20:27:16 +0200 Date: Sun, 6 Nov 2005 20:27:15 +0200 (EET) From: Pekka Savola To: Joe Touch In-Reply-To: <43485D5D.7040208@isi.edu> Message-ID: References: <4210B534.1010302@isi.edu> <426ED950.2010404@isi.edu> <43485D5D.7040208@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org Subject: [tcpm] Re: draft-ietf-tcpm-tcp-antispoof-01.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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Sat, 8 Oct 2005, Joe Touch wrote: >> 8.1. Normative References >> >> As this is not a standards document, this section has no meaning. >> >> ==> Normative means more than just what's what's MUST or MUST not for a >> standard document. It also means 1) "documents which should be read and >> understood by the reader of this document in order to understand this >> document" and 2) "documents which should be published as stable references >> before this document gets published as RFC". >> >> I think there are a number of references in category 1). There are also a >> couple of others in category 2),e.g., tcpmd5app-01, ikev2/AH, dccp. > > Although I personally agree with you (esp. w.r.t. #1) I've had this > debate before, and my understanding is that "normative" in the IETF > means "refers to a standard to enable a a specificiation". Since this > isn't a spec (standards track), there can be no normative refs. > > If that's not the case, however, somebody in authority holler. ;-) > > My original wording was a bit sarcastic in response to that > understanding, so it has been downgraded to 'None.' FWIW, There's extensive precedent for having Normative references for Informational documents and the IESG not barking on that. -- 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 Sun Nov 06 13:46:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYpX4-0006UY-OL; Sun, 06 Nov 2005 13:46:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYpX2-0006UT-V5 for tcpm@megatron.ietf.org; Sun, 06 Nov 2005 13:46:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14075 for ; Sun, 6 Nov 2005 13:45:55 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYpmU-0001dO-6q for tcpm@ietf.org; Sun, 06 Nov 2005 14:02:19 -0500 Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA6IjCM24463; Sun, 6 Nov 2005 10:45:12 -0800 (PST) Message-ID: <436E4F33.7070209@isi.edu> Date: Sun, 06 Nov 2005 10:45:07 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Pekka Savola References: <4210B534.1010302@isi.edu> <426ED950.2010404@isi.edu> <43485D5D.7040208@isi.edu> In-Reply-To: X-Enigmail-Version: 0.93.0.0 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 Subject: [tcpm] Re: draft-ietf-tcpm-tcp-antispoof-01.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: , Content-Type: multipart/mixed; boundary="===============0902065351==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0902065351== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig11972452B95CDF46AC54BF88" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig11972452B95CDF46AC54BF88 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Sat, 8 Oct 2005, Joe Touch wrote: >>> 8.1. Normative References >>> >>> As this is not a standards document, this section has no meaning. >>> >>> =3D=3D> Normative means more than just what's what's MUST or MUST not= for a >>> standard document. It also means 1) "documents which should be read = and >>> understood by the reader of this document in order to understand this= >>> document" and 2) "documents which should be published as stable >>> references >>> before this document gets published as RFC". >>> >>> I think there are a number of references in category 1). There are >>> also a >>> couple of others in category 2),e.g., tcpmd5app-01, ikev2/AH, dccp. >> >> Although I personally agree with you (esp. w.r.t. #1) I've had this >> debate before, and my understanding is that "normative" in the IETF >> means "refers to a standard to enable a a specificiation". Since this >> isn't a spec (standards track), there can be no normative refs. >> >> If that's not the case, however, somebody in authority holler. ;-) >> >> My original wording was a bit sarcastic in response to that >> understanding, so it has been downgraded to 'None.' >=20 > FWIW, >=20 > There's extensive precedent for having Normative references for > Informational documents and the IESG not barking on that. The IESG isn't the one that barks (they're asleep - consider the TCP roadmap and discussion on the normative ref to an ID); it's the RFC-Editor pass that catches these. Joe --------------enig11972452B95CDF46AC54BF88 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDbk8zE5f5cImnZrsRAg+eAKDxjrFXavG4+7MnijNVXDGjO792HQCfeP/V dSGDtI6zE1wV5SMTx24eX0Q= =v89/ -----END PGP SIGNATURE----- --------------enig11972452B95CDF46AC54BF88-- --===============0902065351== 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 --===============0902065351==-- From tcpm-bounces@ietf.org Sun Nov 06 13:50:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYpbH-0007Ie-Ox; Sun, 06 Nov 2005 13:50:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYpbG-0007IZ-W6 for tcpm@megatron.ietf.org; Sun, 06 Nov 2005 13:50:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14236 for ; Sun, 6 Nov 2005 13:50:17 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYpqi-0001jL-UR for tcpm@ietf.org; Sun, 06 Nov 2005 14:06:41 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA6IoQC03799; Sun, 6 Nov 2005 20:50:26 +0200 Date: Sun, 6 Nov 2005 20:50:26 +0200 (EET) From: Pekka Savola To: Joe Touch In-Reply-To: <436E4F33.7070209@isi.edu> Message-ID: References: <4210B534.1010302@isi.edu> <426ED950.2010404@isi.edu> <43485D5D.7040208@isi.edu> <436E4F33.7070209@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org Subject: [tcpm] Re: draft-ietf-tcpm-tcp-antispoof-01.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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Sun, 6 Nov 2005, Joe Touch wrote: >> There's extensive precedent for having Normative references [in] >> Informational documents and the IESG not barking on that. > > The IESG isn't the one that barks (they're asleep - consider the TCP > roadmap and discussion on the normative ref to an ID); it's the > RFC-Editor pass that catches these. (Sorry, above I wrote "Normative references for", I meant to write "Normative references in".) There is also extensive precedent for having norm references in informational documents and the RFC-editor appears to be fine with that. -- 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 Sun Nov 06 16:43:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYsI5-0004d7-Eq; Sun, 06 Nov 2005 16:43:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYsI3-0004cx-SI for tcpm@megatron.ietf.org; Sun, 06 Nov 2005 16:43:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21880 for ; Sun, 6 Nov 2005 16:42:39 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYsXW-0005jW-Kp for tcpm@ietf.org; Sun, 06 Nov 2005 16:59:04 -0500 Received: from [70.209.177.148] (148.sub-70-209-177.myvzw.com [70.209.177.148]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA6Lg8M04245; Sun, 6 Nov 2005 13:42:08 -0800 (PST) Message-ID: <436E78A9.10609@isi.edu> Date: Sun, 06 Nov 2005 13:42:01 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Pekka Savola References: <4210B534.1010302@isi.edu> <426ED950.2010404@isi.edu> <43485D5D.7040208@isi.edu> <436E4F33.7070209@isi.edu> In-Reply-To: X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tcpm@ietf.org Subject: [tcpm] Re: draft-ietf-tcpm-tcp-antispoof-01.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: , Content-Type: multipart/mixed; boundary="===============0563005716==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0563005716== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC22D677875A0A53420431614" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC22D677875A0A53420431614 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Sun, 6 Nov 2005, Joe Touch wrote: >>> There's extensive precedent for having Normative references [in] >>> Informational documents and the IESG not barking on that. >> >> The IESG isn't the one that barks (they're asleep - consider the TCP >> roadmap and discussion on the normative ref to an ID); it's the >> RFC-Editor pass that catches these. >=20 > (Sorry, above I wrote "Normative references for", I meant to write > "Normative references in".) >=20 > There is also extensive precedent for having norm references in > informational documents and the RFC-editor appears to be fine with that= =2E Some. The larger issue is what it means to have a normative ref in a doc that isn't itself a spec. Normative means 'referring to another spec in a dependent way'. Sure, the other part is a spec - but how can a non-spec 'depend' on a spec? Joe --------------enigC22D677875A0A53420431614 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDbnipE5f5cImnZrsRAglEAJ4k4dFfPO7HjZyR8598WF5M0dXu0ACfRT0O hN04wOMu3cr7Gz6/MEmsPyk= =bpiV -----END PGP SIGNATURE----- --------------enigC22D677875A0A53420431614-- --===============0563005716== 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 --===============0563005716==-- From tcpm-bounces@ietf.org Sun Nov 06 16:52:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYsQy-0007aT-N4; Sun, 06 Nov 2005 16:52:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYsQx-0007aK-Av for tcpm@megatron.ietf.org; Sun, 06 Nov 2005 16:52:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22255 for ; Sun, 6 Nov 2005 16:51:50 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYsgR-0005xR-6p for tcpm@ietf.org; Sun, 06 Nov 2005 17:08:15 -0500 Received: from [70.209.177.148] (148.sub-70-209-177.myvzw.com [70.209.177.148]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA6LoxM06713; Sun, 6 Nov 2005 13:50:59 -0800 (PST) Message-ID: <436E7ABE.1000004@isi.edu> Date: Sun, 06 Nov 2005 13:50:54 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 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 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="===============0667311284==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0667311284== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2831BE4D6E54B781B9FB61DA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2831BE4D6E54B781B9FB61DA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > It may be needless to say this, but in any case.. >=20 > I re-read draft-gont-tcpm-icmp-attacks-05 on the plane. The last rev I= had > read properly was probably -02 or -03. I was very pleased with this > version; I was much more skeptic of certain parts of the doc (e.g., PMT= UD > attacks) before, but I think the document is well written and convincin= g > now. >=20 > I'd recommend adopting this as a WG item (provided that Fernando would = then > lift the "no derivative works" clause, because otherwise the doc can't = be > used in the IETF process).=20 IMO, the document - at least - needs to have the title changed and tone of the argument changed as well. These are not - and cannot be put forth as - security issues. We can talk about them being useful in how they mitigate the effect of stale packets, and then - as a corellary - how some attacks emulate stale packets. The same is true for other aspects that tone down response to what could be fluctuating conditions. However, focusing on this as an attack issue is inappropriate; the remaining (in-window, or on-path) attacks are still too easy to consider these attack mitigations as a focus. (that said, I would agree that if the focus were changed, it would be a useful WG doc) I've made these points before; unfortunately, the current revision did not address them. Joe --------------enig2831BE4D6E54B781B9FB61DA 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDbnq+E5f5cImnZrsRAj45AJ9wuF00QLkrAxN6fTeuWEP43GCZBACg/GBj WNKF82o08TBS1emFE9Ajvp4= =zmNs -----END PGP SIGNATURE----- --------------enig2831BE4D6E54B781B9FB61DA-- --===============0667311284== 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 --===============0667311284==-- From tcpm-bounces@ietf.org Sun Nov 06 19:22:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYumI-0008CL-1e; Sun, 06 Nov 2005 19:22:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYumG-0008CG-1Q for tcpm@megatron.ietf.org; Sun, 06 Nov 2005 19:22:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29139 for ; Sun, 6 Nov 2005 19:21:58 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYv1j-0000tu-8y for tcpm@ietf.org; Sun, 06 Nov 2005 19:38:25 -0500 Received: (qmail 10876 invoked from network); 7 Nov 2005 00:21:02 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 7 Nov 2005 00:21:02 -0000 Message-Id: <6.2.0.14.0.20051106160757.0432ea98@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sun, 06 Nov 2005 16:21:49 -0800 To: Joe Touch , Pekka Savola From: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 In-Reply-To: <436E7ABE.1000004@isi.edu> References: <436E7ABE.1000004@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 01:50 p.m. 06/11/2005, Joe Touch wrote: > > I'd recommend adopting this as a WG item (provided that Fernando would then > > lift the "no derivative works" clause, because otherwise the doc can't be > > used in the IETF process). > >IMO, the document - at least - needs to have the title changed Mark Allman has suggested "TCP validation of ICMP messages". This could be a possible alternative title for the document, if that's an issue. >and tone >of the argument changed as well. These are not - and cannot be put forth >as - security issues. I disagree. The draft explains how an attacker can take advantage of the described vulnerabilities. And, indeed, the ICMP-based connection-reset attack is much more trivial to perform than its TCP-based counterpart. >We can talk about them being useful in how they mitigate the effect of >stale packets, and then - as a corellary - how some attacks emulate >stale packets. This could be true for the TCP sequence number check. But none of the attack-specific counter-measures have anything to do with stale packets. If anything, they have to do with checking progress on the connection. If you just mitigate stale packets, you are still vulnerable to in-window attacks. The draft solves in-window attacks, which, as a corellary, solves the case of stale packets. I agree that I could add some text on the counter-measures also solving the case of stale packets, but not the opposite (for the reasons stated above). >However, focusing on this as an attack issue is inappropriate; the >remaining (in-window, or on-path) attacks are still too easy to consider >these attack mitigations as a focus. How can you perform in-window attacks if you have all the attack-specific counter-measures implemented? You're just referring to the TCP sequence number check, which is not meant to be a counter-measure, but rather a very basic check we should be performing, that can be used as a building block for counter-measures (eh, the PMTUD specific fix). Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 07 14:09:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCNO-0001lz-Sg; Mon, 07 Nov 2005 14:09:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCNN-0001kv-CX for tcpm@megatron.ietf.org; Mon, 07 Nov 2005 14:09:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01029 for ; Mon, 7 Nov 2005 14:09:27 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCd1-0005LJ-0t for tcpm@ietf.org; Mon, 07 Nov 2005 14:26:04 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA7J58M23658; Mon, 7 Nov 2005 11:05:08 -0800 (PST) Message-ID: <436F7C08.9020104@isi.edu> Date: Mon, 07 Nov 2005 08:08:40 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> In-Reply-To: <6.2.0.14.0.20051106160757.0432ea98@localhost> X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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="===============1903407472==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1903407472== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCBBB848BC0F9B671D7948376" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCBBB848BC0F9B671D7948376 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 01:50 p.m. 06/11/2005, Joe Touch wrote: >=20 >> > I'd recommend adopting this as a WG item (provided that Fernando >> would then >> > lift the "no derivative works" clause, because otherwise the doc >> can't be >> > used in the IETF process). >> >> IMO, the document - at least - needs to have the title changed >=20 > Mark Allman has suggested "TCP validation of ICMP messages". This could= > be a possible alternative title for the document, if that's an issue. Possible. I'm not sure 'validation' captures what I feel are basically 'sanity checks', but it might. >> and tone >> of the argument changed as well. These are not - and cannot be put for= th >> as - security issues. >=20 > I disagree. The draft explains how an attacker can take advantage of th= e > described vulnerabilities. And, indeed, the ICMP-based connection-reset= > attack is much more trivial to perform than its TCP-based counterpart. It does NOT address the substantial vulnerabilities that remain, or the effect of interpreting all invalid exchanges as attacks (which I feel is both overkill and inappropriate). >> We can talk about them being useful in how they mitigate the effect of= >> stale packets, and then - as a corellary - how some attacks emulate >> stale packets. >=20 > This could be true for the TCP sequence number check. But none of the > attack-specific counter-measures have anything to do with stale packets= =2E > If anything, they have to do with checking progress on the connection. Which is another kind of validity, but one that assumes that a connection making progress should not also incur these kinds of signals. I've described cases where non-malicious systems can behave this way. > If you just mitigate stale packets, you are still vulnerable to > in-window attacks. The draft solves in-window attacks, which, as a > corellary, solves the case of stale packets. It doesn't identify attacks; it (over)interprets certain behaviors as attacks. I agree that making progress might be a reason to change the current behavior of TCP/ICMP because TCP is making progress and the ICMPs can be considered irrelevent - NOT AN ATTACK. Again, this is about the tone of the doc. > I agree that I could add some text on the counter-measures also solving= > the case of stale packets, but not the opposite (for the reasons stated= > above). >=20 >> However, focusing on this as an attack issue is inappropriate; the >> remaining (in-window, or on-path) attacks are still too easy to consid= er >> these attack mitigations as a focus. >=20 > How can you perform in-window attacks if you have all the > attack-specific counter-measures implemented? One way would be by deploying this system ;-) The 'attack' has succeeded if it causes changes to legitimate, correct TCP/ICMP interaction. If you shut all in-window attacks, you've disabled a functioning feature. Otherwise, you're arguing about when you know the difference between an attack and a non-attack. Joe --------------enigCBBB848BC0F9B671D7948376 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDb3wIE5f5cImnZrsRAoeHAJ4jNZoxGWHu/n5nYp6I78x2cW5t2QCgvyDd /HrP3X7ILlzBLbDnb/ibwqA= =MWxv -----END PGP SIGNATURE----- --------------enigCBBB848BC0F9B671D7948376-- --===============1903407472== 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 --===============1903407472==-- From tcpm-bounces@ietf.org Mon Nov 07 14:25:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCcw-0006wO-9d; Mon, 07 Nov 2005 14:25:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCcv-0006wJ-LI for tcpm@megatron.ietf.org; Mon, 07 Nov 2005 14:25:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02010 for ; Mon, 7 Nov 2005 14:25:31 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCsX-0005mh-IK for tcpm@ietf.org; Mon, 07 Nov 2005 14:42:09 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id jA7JPlAW000744; Mon, 7 Nov 2005 11:25:48 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 9B11D77AC21; Mon, 7 Nov 2005 14:25:46 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lights MIME-Version: 1.0 Date: Mon, 07 Nov 2005 14:25:46 -0500 Message-Id: <20051107192546.9B11D77AC21@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Ted Faber , touch@isi.edu Subject: [tcpm] antispoof document 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="===============0609604146==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0609604146== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- Joe has told us that he has rolled all the comments received into the latest version of the anti-spoof document (draft-ietf-tcpm-tcp-antispoof-02.txt). We are hopeful that we are quite close to a WGLC on this document. If you have not yet read it or have not read it recently, please take a look at it and raise substantive issues soon. Thanks! Mark and Ted --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDb6o6WyrrWs4yIs4RArpAAJ97OoxmFoxm4nxOINyQV1s1I457XACfTlE6 hzEumAtKywf1aofVKdS/438= =YJYa -----END PGP SIGNATURE----- --=_bOundary-- --===============0609604146== 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 --===============0609604146==-- From tcpm-bounces@ietf.org Mon Nov 07 17:35:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFag-00020q-24; Mon, 07 Nov 2005 17:35:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFae-000201-SF for tcpm@megatron.ietf.org; Mon, 07 Nov 2005 17:35:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13315 for ; Mon, 7 Nov 2005 17:35:23 -0500 (EST) 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 1EZFqK-0002qH-Kt for tcpm@ietf.org; Mon, 07 Nov 2005 17:52:02 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2005 14:35:42 -0800 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 jA7MYxOH016684; Mon, 7 Nov 2005 14:35:40 -0800 (PST) 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.211); Mon, 7 Nov 2005 14:35:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] draft-bonica-tcp-auth-00 Date: Mon, 7 Nov 2005 14:35:36 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58BFFAA7@xmb-sjc-21c.amer.cisco.com> Thread-Topic: [tcpm] draft-bonica-tcp-auth-00 Thread-Index: AcW9QjjD2HgRvzIMRayaLgeN6C+kbAmpV6GA From: "Anantha Ramaiah \(ananth\)" To: "Ted Faber" , "Ron Bonica" X-OriginalArrivalTime: 07 Nov 2005 22:35:38.0844 (UTC) FILETIME=[93EBA1C0:01C5E3EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I see that this is going to be presented in TCPM on Thursday. I have few comments based on our experiences so far in the key rollover stuff. - Firstly it is really not needed to extend TCP for supporting key-rollover. We have some implicit methods to do it today. - Also it is probably not neeeded have an explicit key-identifier (authentication element)in each and every TCP segment being sent out. - The draft also talks about providing the ability to switch to multiple algorithms during the life of a single connection. This appears to be a overkill. The reason I am saying this because we have MD5 today which is being deployed "on and off" depending on the on the security requirements of the customers. Now since MD5 is probably prone to collision attacks after "some volume" of data transfer, it is probably desirable to have periodic key changes which is where the topic of key-rollover commences from. So all I am wondering is in cases where MD5 is used to protect the sessions, doesn't periodic key-rollover help? Where is the need for changing algorithm type coming from?=20 - Like the draft acknowledges, there is a problem that it oversubscribes the TCP option space. While this may seem ok, in reality it probably isn't. We have seen several customer configurations employing timestamps, selective-acks and MD5.=20 Just wanted to point out that we did think about a new TCP option a year back when we first had customers asking us for key-rollover and we dropped it because of the issues above. The implicit methods without changing TCP protocol seems to do the desired job necessary to accomplish rollover.=20 $0.02, -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Ted Faber > Sent: Monday, September 19, 2005 10:40 AM > To: Ron Bonica > Cc: tcpm@ietf.org > Subject: Re: [tcpm] draft-bonica-tcp-auth-00 >=20 > On Sat, Sep 17, 2005 at 10:27:46AM -0400, Ron Bonica wrote: > > Please consider the following draft as an individual submission: > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > [snip] > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-00.txt >=20 > I skimmed this over, and (with my co-chair hat off) the only=20 > real concerns I have with this are: >=20 > * It seems like a bit of a band-aid on the MD5 TCP stuff, > without fixing the real problem that it requires configuration > coordination. > * I think that as specified you're free from problems cause dby > any but the most ridiculous clock skew, but adding a paragraph > indicating that's the case probably wouldn't hurt. > Specifically you might want to address when an endpoint can > discard authentication entities. You might also want to > briefly explain that a host receiving a packet authenticated > with an authentication element that the receiving endpoint > does not believe has passed its start time is not an error > because clocks may have skewed. >=20 > Do others have deeper objections? >=20 > -- > Ted Faber > http://www.isi.edu/~faber PGP:=20 > http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See=20 > http://www.isi.edu/~faber/FAQ.html#SIG >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 07 18:28:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZGPu-00088d-N7; Mon, 07 Nov 2005 18:28:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZGPr-00088U-TI for tcpm@megatron.ietf.org; Mon, 07 Nov 2005 18:28:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16976 for ; Mon, 7 Nov 2005 18:28:18 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZGfY-0004Xl-3x for tcpm@ietf.org; Mon, 07 Nov 2005 18:44:57 -0500 Received: (qmail 30560 invoked from network); 7 Nov 2005 23:26:39 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 7 Nov 2005 23:26:39 -0000 Message-Id: <6.2.0.14.0.20051107151117.01f2b558@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 07 Nov 2005 15:27:16 -0800 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 In-Reply-To: <436F7C08.9020104@isi.edu> References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 08:08 a.m. 07/11/2005, Joe Touch wrote: > >> and tone > >> of the argument changed as well. These are not - and cannot be put forth > >> as - security issues. > > > > I disagree. The draft explains how an attacker can take advantage of the > > described vulnerabilities. And, indeed, the ICMP-based connection-reset > > attack is much more trivial to perform than its TCP-based counterpart. > >It does NOT address the substantial vulnerabilities that remain, or the You mean man in the middle attacks, or what? >effect of interpreting all invalid exchanges as attacks (which I feel is >both overkill and inappropriate). You implement the proposed mechanisms as counter-measures for ICMP-based attacks. In the event some packet is not part of an attack, the counter-measures will not hurt you, anyway, because ICMP is unreliable. > >> We can talk about them being useful in how they mitigate the effect of > >> stale packets, and then - as a corellary - how some attacks emulate > >> stale packets. > > > > This could be true for the TCP sequence number check. But none of the > > attack-specific counter-measures have anything to do with stale packets. > > If anything, they have to do with checking progress on the connection. > >Which is another kind of validity, but one that assumes that a >connection making progress should not also incur these kinds of signals. >I've described cases where non-malicious systems can behave this way. Yes. And what is the problem if an ICMP message does not pass the proposed checks, not because it's part of an attack, but because it was caused by a stale TCP segment or whatever? > > If you just mitigate stale packets, you are still vulnerable to > > in-window attacks. The draft solves in-window attacks, which, as a > > corellary, solves the case of stale packets. > >It doesn't identify attacks; it (over)interprets certain behaviors as >attacks. From the receiver's point of view, you cannot tell the difference. That's why, given the current hostile environments, it's fair to think bad guys may be behind these packets. >I agree that making progress might be a reason to change the current >behavior of TCP/ICMP because TCP is making progress and the ICMPs can be >considered irrelevent - NOT AN ATTACK. The draft does not mean that . It just means that we will implement a set of mechanisms that in the presence of blind ICMP-based attacks, it will protect us from them. It does not aim to guess whether the packet correspond to an attack, or not. And if there's some wording that suggests that, I will try to make it clear. > >> However, focusing on this as an attack issue is inappropriate; the > >> remaining (in-window, or on-path) attacks are still too easy to consider > >> these attack mitigations as a focus. > > > > How can you perform in-window attacks if you have all the > > attack-specific counter-measures implemented? > >One way would be by deploying this system ;-) Have a look at the vulnerability reports of virtually every major vendor. >The 'attack' has succeeded >if it causes changes to legitimate, correct TCP/ICMP interaction. No, the attack has succeeded if you have been DoS'ed. >If you shut all in-window attacks, you've disabled a functioning >feature. A feature you cannot depend on? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 07 20:58:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIkN-0003ko-1l; Mon, 07 Nov 2005 20:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIkK-0003kd-Lq for tcpm@megatron.ietf.org; Mon, 07 Nov 2005 20:58:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00625 for ; Mon, 7 Nov 2005 20:57:33 -0500 (EST) Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJ00-0001yw-9o for tcpm@ietf.org; Mon, 07 Nov 2005 21:14:15 -0500 Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1EZIjp-0001i2-00; Tue, 08 Nov 2005 01:57:30 +0000 Date: Tue, 8 Nov 2005 01:57:27 +0000 (GMT) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk To: Mark Allman Subject: Re: [tcpm] antispoof document In-Reply-To: <20051107192546.9B11D77AC21@guns.icir.org> Message-ID: References: <20051107192546.9B11D77AC21@guns.icir.org> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *1EZIjp-0001i2-00*yxDupcjOY2c* (SECM, UniS) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tcpm@ietf.org, Ted Faber , touch@isi.edu 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, 7 Nov 2005, Mark Allman wrote: > Joe has told us that he has rolled all the comments received into the > latest version of the anti-spoof document > (draft-ietf-tcpm-tcp-antispoof-02.txt). I think calling this antispoofing sends the wrong message; it sounds like you're defending against deliberate attacks, when you may not be. Can't we call this draft 'Sanity checking of observed TCP endpoint behaviour', or somesuch? (This is really about the tone of the doc.) thanks, L. > We are hopeful that we are quite close to a WGLC on this document. > If you have not yet read it or have not read it recently, please > take a look at it and raise substantive issues soon. > > Thanks! > > Mark and Ted _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 07 21:38:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJNL-0008Qz-DZ; Mon, 07 Nov 2005 21:38:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJNJ-0008O7-9o for tcpm@megatron.ietf.org; Mon, 07 Nov 2005 21:38:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03398 for ; Mon, 7 Nov 2005 21:37:50 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJd0-000391-1Q for tcpm@ietf.org; Mon, 07 Nov 2005 21:54:32 -0500 Received: from lars.ietf64.ietf.org (pp107-126.bctel.ca [209.52.107.126]) by kyoto.netlab.nec.de (Postfix) with ESMTP id DB8E71BAC4D; Tue, 8 Nov 2005 03:38:04 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.ietf64.ietf.org (Postfix) with ESMTP id 2D66540A24A; Mon, 7 Nov 2005 18:38:03 -0800 (PST) In-Reply-To: <20051024164244.GE54696@pun.isi.edu> References: <447BB19E14004A4388CB9A864D2BA7630DB0FB@hq-ex-6.brocade.com> <20051024164244.GE54696@pun.isi.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: From: Lars Eggert Subject: Re: [tcpm] Sequence number checking for incoming RST segments Date: Mon, 7 Nov 2005 18:38:00 -0800 To: Ted Faber X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: tcpm@ietf.org, Indraneel Ghosh 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="===============0691360704==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0691360704== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14-638941581; protocol="application/pkcs7-signature" --Apple-Mail-14-638941581 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Oct 24, 2005, at 9:42, Ted Faber wrote: > I'd start here: http://www.ietf.org/internet-drafts/draft-ietf-tcpm- > tcpsecure-03.txt > > Then I'd check the tcpm archives for discussion on that topic. > there's > been a bit. Those are here: http://www1.ietf.org/mail-archive/web/ > tcpm/current/index.html FYI, the latest stable FreeBSD-6.0 also seems to implement (some variant of) tcpsecure: "The RST handling of the FreeBSD TCP stack has been improved to make reset attacks as difficult as possible while maintaining compatibility with the widest range of TCP stacks. The algorithm is as follows: For connections in the ESTABLISHED state, only resets with sequence numbers exactly matching last_ack_sent will cause a reset; all other segments will be silently dropped. For connections in all other states, a reset anywhere in the window will cause the connection to be reset. All other segments will be silently dropped. Note that this behavior technically violates the RFC 793 specification; the conventional (but less secure) behavior can be restored by setting a new sysctl net.inet.tcp.insecure_rst to 1. [MERGED]" http://www.freebsd.org/releases/6.0R/relnotes-i386.html Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-14-638941581 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDUxMTA4MDIzODAwWjAjBgkqhkiG9w0BCQQxFgQU//pwK3X29J/QCrg+C17M 0gfc+DowgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBABb9toJh5uWmDBHGEyooqhYp9pAJAXCo1wk+SYPZZ5V2hPJJaVdU2eFBgvT+r9LINz5g0fNx PdYnPUJbM4m9KhWkUr9zOl4Bj191PkeLzsl79TG5puad6iNvIhm03rOaSJz/NVirqfvP2UvfRRpV x4avq5ubxJAxh+RR1McM+y11HF3FUiovFEBi7jDTzpUGJKQvVxA0wNrE6mb7mVqfy/F9TuPRV8yh sbjlcju8EBRS3BiFeGX0sTcN+XnN1HHmcs59zDeim9CrIA6NIIJNfNxxPlBiKkK7EbeXtbwSJPzt rHYxF+2xoWRue+IcV608gemiF4CyFA8cCJ1koKKmnOEAAAAAAAA= --Apple-Mail-14-638941581-- --===============0691360704== 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 --===============0691360704==-- From tcpm-bounces@ietf.org Mon Nov 07 23:49:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZLQS-0005xF-T8; Mon, 07 Nov 2005 23:49:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZLQQ-0005v5-Mw for tcpm@megatron.ietf.org; Mon, 07 Nov 2005 23:49:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10007 for ; Mon, 7 Nov 2005 23:49:13 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZLgA-0006wc-Mv for tcpm@ietf.org; Tue, 08 Nov 2005 00:05:55 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA84cAM01194; Mon, 7 Nov 2005 20:38:10 -0800 (PST) Message-ID: <43702BB2.4000407@isi.edu> Date: Mon, 07 Nov 2005 20:38:10 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> In-Reply-To: <6.2.0.14.0.20051107151117.01f2b558@localhost> X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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="===============0621962511==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0621962511== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9BC1029587A2ABF885712510" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9BC1029587A2ABF885712510 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 08:08 a.m. 07/11/2005, Joe Touch wrote: >=20 >> >> and tone >> >> of the argument changed as well. These are not - and cannot be put >> forth >> >> as - security issues. >> > >> > I disagree. The draft explains how an attacker can take advantage of= >> the >> > described vulnerabilities. And, indeed, the ICMP-based connection-re= set >> > attack is much more trivial to perform than its TCP-based counterpar= t. >> >> It does NOT address the substantial vulnerabilities that remain, or th= e >=20 > You mean man in the middle attacks, or what? Yes. >> effect of interpreting all invalid exchanges as attacks (which I feel = is >> both overkill and inappropriate). >=20 > You implement the proposed mechanisms as counter-measures for ICMP-base= d > attacks. In the event some packet is not part of an attack, the > counter-measures will not hurt you, anyway, because ICMP is unreliable.= We've been over this one before; you make the system less functional by dismissing correct ICMPs that end up reaching you. >> >> We can talk about them being useful in how they mitigate the effect= of >> >> stale packets, and then - as a corellary - how some attacks emulate= >> >> stale packets. >> > >> > This could be true for the TCP sequence number check. But none of th= e >> > attack-specific counter-measures have anything to do with stale >> packets. >> > If anything, they have to do with checking progress on the connectio= n. >> >> Which is another kind of validity, but one that assumes that a >> connection making progress should not also incur these kinds of signal= s. >> I've described cases where non-malicious systems can behave this way. >=20 > Yes. And what is the problem if an ICMP message does not pass the > proposed checks, not because it's part of an attack, but because it was= > caused by a stale TCP segment or whatever? Stale is OK. The cases I'm talking about are TCP connections making progress over multipath routing where one path is flakey and sends ICMPs. That's not stale. >> > If you just mitigate stale packets, you are still vulnerable to >> > in-window attacks. The draft solves in-window attacks, which, as a >> > corellary, solves the case of stale packets. >> >> It doesn't identify attacks; it (over)interprets certain behaviors as >> attacks. >=20 > From the receiver's point of view, you cannot tell the difference. > That's why, given the current hostile environments, it's fair to think > bad guys may be behind these packets. So why aren't ALL packets considered an attack in such an environment? Yes, it's fair to think that bad guys MAY be behind the packets, but only if you also think that good guys MAY as well. I consider it dangerous to consider correct behavior as an attack. >> I agree that making progress might be a reason to change the current >> behavior of TCP/ICMP because TCP is making progress and the ICMPs can = be >> considered irrelevent - NOT AN ATTACK. >=20 > The draft does not mean that . It just means that we will implement a > set of mechanisms that in the presence of blind ICMP-based attacks, it > will protect us from them. It does not aim to guess whether the packet > correspond to an attack, or not. Yes it does; it guesses that any unexpected ICMP _is_ an attack that should thus be ignored. =2E.. >> If you shut all in-window attacks, you've disabled a functioning >> feature. >=20 > A feature you cannot depend on? A feature that works for legitimate hosts. Short of doing authentication, you can't "depend" on any packet. Joe --------------enig9BC1029587A2ABF885712510 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDcCuyE5f5cImnZrsRAlGMAKDF7QxBluSVcCfsY47TEW5GD9DKSACfRxHf 3744REcBJ0XCl11z5SXJfok= =rdeC -----END PGP SIGNATURE----- --------------enig9BC1029587A2ABF885712510-- --===============0621962511== 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 --===============0621962511==-- From tcpm-bounces@ietf.org Tue Nov 08 00:21:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZLvO-0006DG-A8; Tue, 08 Nov 2005 00:21:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZLvM-0006D3-4v for tcpm@megatron.ietf.org; Tue, 08 Nov 2005 00:21:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11239 for ; Tue, 8 Nov 2005 00:21:10 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZMB4-0007bW-TD for tcpm@ietf.org; Tue, 08 Nov 2005 00:37:52 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA85Kqm11520; Tue, 8 Nov 2005 07:20:53 +0200 Date: Tue, 8 Nov 2005 07:20:52 +0200 (EET) From: Pekka Savola To: Joe Touch Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 In-Reply-To: <43702BB2.4000407@isi.edu> Message-ID: References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tcpm@ietf.org, 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, 7 Nov 2005, Joe Touch wrote: >>> Which is another kind of validity, but one that assumes that a >>> connection making progress should not also incur these kinds of signals. >>> I've described cases where non-malicious systems can behave this way. >> >> Yes. And what is the problem if an ICMP message does not pass the >> proposed checks, not because it's part of an attack, but because it was >> caused by a stale TCP segment or whatever? > > Stale is OK. The cases I'm talking about are TCP connections making > progress over multipath routing where one path is flakey and sends > ICMPs. That's not stale. Uhh. So, could you be a bit more specific on what you proposing instead? Ignore all ICMPs, always? I don't see how the mechanisms ICMP errors draft make this any worse compared to vanilla TCP which honors ICMP. Actually this spec makes this better, because errors in synchronized states are treated as soft errors and the host does _not_ reset the sessions. -- 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 Nov 08 12:24:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXCl-0004SL-SP; Tue, 08 Nov 2005 12:24:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXCl-0004S6-0O for tcpm@megatron.ietf.org; Tue, 08 Nov 2005 12:24:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18898 for ; Tue, 8 Nov 2005 12:23:52 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZXSa-0001k6-M0 for tcpm@ietf.org; Tue, 08 Nov 2005 12:40:42 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA8HJfM07045; Tue, 8 Nov 2005 09:19:41 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jA8HJfX0086605; Tue, 8 Nov 2005 09:19:41 -0800 (PST) (envelope-from faber) Date: Tue, 8 Nov 2005 09:19:41 -0800 From: Ted Faber To: Pekka Savola Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 Message-ID: <20051108171941.GA86519@hut.isi.edu> References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.1i 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: 244a2fd369eaf00ce6820a760a3de2e8 Cc: tcpm@ietf.org, Fernando Gont , Joe Touch 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="===============0924106321==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0924106321== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 08, 2005 at 07:20:52AM +0200, Pekka Savola wrote: > I don't see how the mechanisms ICMP errors draft make this any worse=20 > compared to vanilla TCP which honors ICMP. Actually this spec makes=20 > this better, because errors in synchronized states are treated as soft=20 > errors and the host does _not_ reset the sessions. I think a reasonable interpretation of 1122 says that the TCP connection SHOULD reset. Relevant sections include Section 3.2.2.1: A Destination Unreachable message that is received MUST be reported to the transport layer. The transport layer SHOULD use the information appropriately; for example, see Sections 4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose. A Destination Unreachable message that is received with code 0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a routing transient and MUST therefore be interpreted as only a hint, not proof, that the specified destination is unreachable [IP:11]. For example, it MUST NOT be used as proof of a dead gateway (see Section 3.3.1). And Section 4.2.3.9 ICMP messages (which is too long to excerpt), says that hard errors (ICMP Destination Unreachable 2-4) SHOULD abort the connection. As I read it, an established connection receiving a hard error has some discretion as to whether to abort the TCP connection, and that the internal sanity checks (e.g. checking TCP sequence numbers) that the draft advocates would be an excellent mechanism for deciding when to exercise that discretion. That's my reading, and I'm not sure that someone else wouldn't read it differently. --=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 --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDcN4taUz3f+Zf+XsRAjg2AJ9ebFWEW+14xuAN0kPLEboriBF+JQCdEUHg bc6MyTB3hyylYMww0rjokHo= =PV9i -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- --===============0924106321== 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 --===============0924106321==-- From tcpm-bounces@ietf.org Tue Nov 08 13:09:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXui-0002uQ-OZ; Tue, 08 Nov 2005 13:09:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXug-0002rU-Oe for tcpm@megatron.ietf.org; Tue, 08 Nov 2005 13:09:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23217 for ; Tue, 8 Nov 2005 13:09:16 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYAW-0003YB-Sz for tcpm@ietf.org; Tue, 08 Nov 2005 13:26:06 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA8I49M23334; Tue, 8 Nov 2005 10:04:09 -0800 (PST) Message-ID: <4370E895.5020805@isi.edu> Date: Tue, 08 Nov 2005 10:04:05 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> In-Reply-To: X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: tcpm@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============1262908532==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1262908532== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC90C4B26BDAC3745004E5325" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC90C4B26BDAC3745004E5325 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Mon, 7 Nov 2005, Joe Touch wrote: >>>> Which is another kind of validity, but one that assumes that a >>>> connection making progress should not also incur these kinds of >>>> signals. >>>> I've described cases where non-malicious systems can behave this way= =2E >>> >>> Yes. And what is the problem if an ICMP message does not pass the >>> proposed checks, not because it's part of an attack, but because it w= as >>> caused by a stale TCP segment or whatever? >> >> Stale is OK. The cases I'm talking about are TCP connections making >> progress over multipath routing where one path is flakey and sends >> ICMPs. That's not stale. >=20 > Uhh. So, could you be a bit more specific on what you proposing > instead? Ignore all ICMPs, always? No. I favor checking the staleness of ICMPs and checking whether signed payloads are intact before checking such staleness. Non-stale ICMPs, properly signed if signed, should be acted on. (with regard to the signing stuff - e.g., IPsec or TCP/MD5, none of the discussion I posted to the list made it into the draft) > I don't see how the mechanisms ICMP errors draft make this any worse > compared to vanilla TCP which honors ICMP. Actually this spec makes > this better, because errors in synchronized states are treated as soft > errors and the host does _not_ reset the sessions. There are cases where this throws away ICMPs that are not attacks. I don't consider that making things better. Joe --------------enigC90C4B26BDAC3745004E5325 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDcOiYE5f5cImnZrsRAlPnAKDyUYN67R9L9RDDfDwr7B55m/jUdQCeKL3j dPAiO7xYcuvsKQZT/G/v6O0= =tQ6B -----END PGP SIGNATURE----- --------------enigC90C4B26BDAC3745004E5325-- --===============1262908532== 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 --===============1262908532==-- From tcpm-bounces@ietf.org Tue Nov 08 19:36:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZdxH-00048x-A8; Tue, 08 Nov 2005 19:36:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZdxG-00046z-6t for tcpm@megatron.ietf.org; Tue, 08 Nov 2005 19:36:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28639 for ; Tue, 8 Nov 2005 19:36:19 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZeD6-0001qz-TD for tcpm@ietf.org; Tue, 08 Nov 2005 19:53:13 -0500 Received: (qmail 4663 invoked from network); 9 Nov 2005 00:35:05 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 9 Nov 2005 00:35:05 -0000 Message-Id: <6.2.0.14.0.20051108163048.0388f238@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 08 Nov 2005 16:35:44 -0800 To: Ted Faber , Pekka Savola From: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 In-Reply-To: <20051108171941.GA86519@hut.isi.edu> References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org, Joe Touch 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 09:19 a.m. 08/11/2005, Ted Faber wrote: >And Section 4.2.3.9 ICMP messages (which is too long to excerpt), says >that hard errors (ICMP Destination Unreachable 2-4) SHOULD abort the >connection. > >As I read it, an established connection receiving a hard error has some >discretion as to whether to abort the TCP connection, and that the >internal sanity checks (e.g. checking TCP sequence numbers) that the >draft advocates would be an excellent mechanism for deciding when to >exercise that discretion. > >That's my reading, and I'm not sure that someone else wouldn't read it >differently. That would be a first step. But it puts you at the starting point of where tcp-secure started. If we don't treat hard errors as soft errors when a connection is in any of the synchronized states, we should be prepared for...mm... an "icmp-secure" draft? Why would attackers bother to perform TCP-based attacks if they can perform them more easily with ICMP? And the solution for ICMP-based conenction-reset attacks is much more trivial than the one for its TCP counter-part. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 08 19:41:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZe1u-0005jB-6d; Tue, 08 Nov 2005 19:41:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZe1s-0005j6-73 for tcpm@megatron.ietf.org; Tue, 08 Nov 2005 19:41:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28916 for ; Tue, 8 Nov 2005 19:41:05 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZeHj-0001xh-PS for tcpm@ietf.org; Tue, 08 Nov 2005 19:57:59 -0500 Received: (qmail 9023 invoked from network); 9 Nov 2005 00:40:16 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 9 Nov 2005 00:40:16 -0000 Message-Id: <6.2.0.14.0.20051108163654.038dd630@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 08 Nov 2005 16:40:55 -0800 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 In-Reply-To: <43702BB2.4000407@isi.edu> References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 08:38 p.m. 07/11/2005, Joe Touch wrote: > >> It does NOT address the substantial vulnerabilities that remain, or the > > > > You mean man in the middle attacks, or what? > >Yes. Look at the name of the attacks: "Blind xxxx". That's the trivial attacks my draft addresses. > >> Which is another kind of validity, but one that assumes that a > >> connection making progress should not also incur these kinds of signals. > >> I've described cases where non-malicious systems can behave this way. > > > > Yes. And what is the problem if an ICMP message does not pass the > > proposed checks, not because it's part of an attack, but because it was > > caused by a stale TCP segment or whatever? > >Stale is OK. The cases I'm talking about are TCP connections making >progress over multipath routing where one path is flakey and sends >ICMPs. That's not stale. That would be completely broken. See the references included in my draft to D. Clark's papers. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 08 21:12:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfRU-0007sM-Uh; Tue, 08 Nov 2005 21:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfRT-0007sH-U4 for tcpm@megatron.ietf.org; Tue, 08 Nov 2005 21:12:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03812 for ; Tue, 8 Nov 2005 21:11:36 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZfhO-000477-9F for tcpm@ietf.org; Tue, 08 Nov 2005 21:28:31 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA929tM28120; Tue, 8 Nov 2005 18:09:55 -0800 (PST) Message-ID: <43715A72.9080109@isi.edu> Date: Tue, 08 Nov 2005 18:09:54 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> In-Reply-To: <6.2.0.14.0.20051108163048.0388f238@localhost> X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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="===============1331530641==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1331530641== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE76D2CEED9F7AC504823FB29" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE76D2CEED9F7AC504823FB29 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: =2E.. > Why would attackers bother to perform TCP-based attacks if they can > perform them more easily with ICMP? TCP attacks are all spoofing based; for some paths, spoofing can be harder to trace, and harder to ingress filter. (this would depend on the path, but there are cases where properties of a path favor TCP attacks rather than ICMP ones) Joe --------------enigE76D2CEED9F7AC504823FB29 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDcVpyE5f5cImnZrsRAtRDAJ0dM0+O6XwMx/1boVKInUqDQd/EQwCfcr85 05N/yAkqtMgYhFvNu7M8hb8= =12aJ -----END PGP SIGNATURE----- --------------enigE76D2CEED9F7AC504823FB29-- --===============1331530641== 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 --===============1331530641==-- From tcpm-bounces@ietf.org Tue Nov 08 21:14:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfUJ-00084R-2N; Tue, 08 Nov 2005 21:14:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfUH-00084K-MF for tcpm@megatron.ietf.org; Tue, 08 Nov 2005 21:14:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03919 for ; Tue, 8 Nov 2005 21:14:30 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZfkD-0004A8-26 for tcpm@ietf.org; Tue, 08 Nov 2005 21:31:25 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA92DHM28737; Tue, 8 Nov 2005 18:13:17 -0800 (PST) Message-ID: <43715B3C.9070304@isi.edu> Date: Tue, 08 Nov 2005 18:13:16 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <6.2.0.14.0.20051108163654.038dd630@localhost> In-Reply-To: <6.2.0.14.0.20051108163654.038dd630@localhost> X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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="===============0175504327==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0175504327== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC42EE3DBDD872A4DF342426C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC42EE3DBDD872A4DF342426C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 08:38 p.m. 07/11/2005, Joe Touch wrote: >=20 >> >> It does NOT address the substantial vulnerabilities that remain, or= >> the >> > >> > You mean man in the middle attacks, or what? >> >> Yes. >=20 > Look at the name of the attacks: "Blind xxxx". That's the trivial > attacks my draft addresses. That doesn't mean the vulnerabilities don't remain. It's not in the title OR the abstract. So they ought to be discussed. >> >> Which is another kind of validity, but one that assumes that a >> >> connection making progress should not also incur these kinds of >> signals. >> >> I've described cases where non-malicious systems can behave this wa= y. >> > >> > Yes. And what is the problem if an ICMP message does not pass the >> > proposed checks, not because it's part of an attack, but because it = was >> > caused by a stale TCP segment or whatever? >> >> Stale is OK. The cases I'm talking about are TCP connections making >> progress over multipath routing where one path is flakey and sends >> ICMPs. That's not stale. >=20 > That would be completely broken. See the references included in my draf= t > to D. Clark's papers. That is the behavior the spec currently requires. But we've already been over that. --------------enigC42EE3DBDD872A4DF342426C 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDcVs9E5f5cImnZrsRArzTAKD7fFf3ERprn4nBzzZrMq4rbs9dJQCdGLnU dmgrNmB52Sih/IVNEciiRcg= =VIo8 -----END PGP SIGNATURE----- --------------enigC42EE3DBDD872A4DF342426C-- --===============0175504327== 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 --===============0175504327==-- From tcpm-bounces@ietf.org Tue Nov 08 22:27:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZgcr-0000PX-0J; Tue, 08 Nov 2005 22:27:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZgcp-0000NR-K5 for tcpm@megatron.ietf.org; Tue, 08 Nov 2005 22:27:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08133 for ; Tue, 8 Nov 2005 22:27:23 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZgsj-0005zH-Qe for tcpm@ietf.org; Tue, 08 Nov 2005 22:44:19 -0500 Received: (qmail 29604 invoked from network); 9 Nov 2005 03:26:40 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 9 Nov 2005 03:26:40 -0000 Message-Id: <6.2.0.14.0.20051108192423.038dbff8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 08 Nov 2005 19:27:32 -0800 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 In-Reply-To: <43715A72.9080109@isi.edu> References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 06:09 p.m. 08/11/2005, Joe Touch wrote: > > Why would attackers bother to perform TCP-based attacks if they can > > perform them more easily with ICMP? > >TCP attacks are all spoofing based; for some paths, spoofing can be >harder to trace, and harder to ingress filter. > >(this would depend on the path, but there are cases where properties of >a path favor TCP attacks rather than ICMP ones) I strongly disagree. ICMP-based attacks don't even depend on IP address sppofing. TCP ones does. Simple ingress/egress filtering serves as a counter-measure for TCP-based attacks. But it does not serve as a counter-measure for ICMP-based ones. ICMP-based attacks have been used for ages. Even by script-kiddies, for taking over IRC channels. Guess why they didn't use TCP-based ones. And guess what a knowledgeable attacker would do. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 08 22:32:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZghZ-0002FK-At; Tue, 08 Nov 2005 22:32:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZghX-0002E1-8b for tcpm@megatron.ietf.org; Tue, 08 Nov 2005 22:32:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08342 for ; Tue, 8 Nov 2005 22:32:15 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZgxS-000675-Hf for tcpm@ietf.org; Tue, 08 Nov 2005 22:49:11 -0500 Received: (qmail 19710 invoked from network); 9 Nov 2005 03:31:43 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 9 Nov 2005 03:31:43 -0000 Message-Id: <6.2.0.14.0.20051108192815.038be230@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 08 Nov 2005 19:31:04 -0800 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 In-Reply-To: <43715B3C.9070304@isi.edu> References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <6.2.0.14.0.20051108163654.038dd630@localhost> <43715B3C.9070304@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 06:13 p.m. 08/11/2005, Joe Touch wrote: > >> >> It does NOT address the substantial vulnerabilities that remain, or > >> the > >> > > >> > You mean man in the middle attacks, or what? > >> > >> Yes. > > > > Look at the name of the attacks: "Blind xxxx". That's the trivial > > attacks my draft addresses. > >That doesn't mean the vulnerabilities don't remain. It's not in the >title OR the abstract. So they ought to be discussed. You are objecting the draft because it does not address attacks it is not meant to address. If you think it would be good to make it clear that it does not address MIM attacks, fine, I can make it clear. But that's not a stop-gap. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 09 03:55:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZljl-0003nF-85; Wed, 09 Nov 2005 03:55:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZljj-0003m5-9w for tcpm@megatron.ietf.org; Wed, 09 Nov 2005 03:55:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23738 for ; Wed, 9 Nov 2005 03:54:51 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZlzh-0005RO-6b for tcpm@ietf.org; Wed, 09 Nov 2005 04:11:50 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA98pCM07475; Wed, 9 Nov 2005 00:51:12 -0800 (PST) Message-ID: <4371B87F.80907@isi.edu> Date: Wed, 09 Nov 2005 00:51:11 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <6.2.0.14.0.20051108163654.038dd630@localhost> <43715B3C.9070304@isi.edu> <6.2.0.14.0.20051108192815.038be230@localhost> In-Reply-To: <6.2.0.14.0.20051108192815.038be230@localhost> X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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="===============1976957858==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1976957858== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig839C59F6D393FFA61DE5B7B2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig839C59F6D393FFA61DE5B7B2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 06:13 p.m. 08/11/2005, Joe Touch wrote: >=20 >> >> >> It does NOT address the substantial vulnerabilities that remain,= or >> >> the >> >> > >> >> > You mean man in the middle attacks, or what? >> >> >> >> Yes. >> > >> > Look at the name of the attacks: "Blind xxxx". That's the trivial >> > attacks my draft addresses. >> >> That doesn't mean the vulnerabilities don't remain. It's not in the >> title OR the abstract. So they ought to be discussed. >=20 > You are objecting the draft because it does not address attacks it is > not meant to address. It seems that either the title or abstract would explain what attacks are being addressed; neither limits this to blind attacks. > If you think it would be good to make it clear that it does not address= > MIM attacks, fine, I can make it clear. Agreed, but that's not the only issue; I've already explained the other. > But that's not a stop-gap. >=20 > Kindest regards, >=20 > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org >=20 >=20 >=20 >=20 --------------enig839C59F6D393FFA61DE5B7B2 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDcbiAE5f5cImnZrsRArwMAKCqtfmyvM3KnbfDDphSHFnT+f+ltwCfZTL1 t86qcU6EktggZxzB1aRe174= =Cllz -----END PGP SIGNATURE----- --------------enig839C59F6D393FFA61DE5B7B2-- --===============1976957858== 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 --===============1976957858==-- From tcpm-bounces@ietf.org Wed Nov 09 03:58:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZln1-0004u2-55; Wed, 09 Nov 2005 03:58:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZlmy-0004tV-Q1 for tcpm@megatron.ietf.org; Wed, 09 Nov 2005 03:58:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23852 for ; Wed, 9 Nov 2005 03:58:13 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZm2x-0005Ua-Nd for tcpm@ietf.org; Wed, 09 Nov 2005 04:15:12 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA98sNM08402; Wed, 9 Nov 2005 00:54:23 -0800 (PST) Message-ID: <4371B93E.5090700@isi.edu> Date: Wed, 09 Nov 2005 00:54:22 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> In-Reply-To: <6.2.0.14.0.20051108192423.038dbff8@localhost> X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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="===============1841738806==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1841738806== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB0A77DB7098859E863EE0970" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB0A77DB7098859E863EE0970 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 06:09 p.m. 08/11/2005, Joe Touch wrote: >=20 >> > Why would attackers bother to perform TCP-based attacks if they can >> > perform them more easily with ICMP? >> >> TCP attacks are all spoofing based; for some paths, spoofing can be >> harder to trace, and harder to ingress filter. >> >> (this would depend on the path, but there are cases where properties o= f >> a path favor TCP attacks rather than ICMP ones) >=20 > I strongly disagree. ICMP-based attacks don't even depend on IP address= > sppofing. TCP ones does. That's what I said above. > Simple ingress/egress filtering serves as a counter-measure for > TCP-based attacks. But it does not serve as a counter-measure for > ICMP-based ones. This depends on the paths, the filters, and the location of the attacker. In some cases, it's easier to spoof a source address than the address of an arbitrary router. > ICMP-based attacks have been used for ages. Even by script-kiddies, for= > taking over IRC channels. >=20 > Guess why they didn't use TCP-based ones. Existence of cases where ICMP is easier than TCP does not preclude cases where the converse is true. JOe --------------enigB0A77DB7098859E863EE0970 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDcbk+E5f5cImnZrsRAsY0AJkB8O1QBPOHBysm9GQWYI77/G1qOACg+WXR cRplg98Yilk+Yk0RU6wn/TE= =BEMH -----END PGP SIGNATURE----- --------------enigB0A77DB7098859E863EE0970-- --===============1841738806== 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 --===============1841738806==-- From tcpm-bounces@ietf.org Wed Nov 09 10:01:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZrRk-0005Km-Sg; Wed, 09 Nov 2005 10:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZrRi-0005K5-R4 for tcpm@megatron.ietf.org; Wed, 09 Nov 2005 10:01:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14300 for ; Wed, 9 Nov 2005 10:00:39 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZrhj-0006qg-O9 for tcpm@ietf.org; Wed, 09 Nov 2005 10:17:41 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA9F0bH27084; Wed, 9 Nov 2005 17:00:38 +0200 Date: Wed, 9 Nov 2005 17:00:37 +0200 (EET) From: Pekka Savola To: Joe Touch Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 In-Reply-To: <4371B93E.5090700@isi.edu> Message-ID: References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> <4371B93E.5090700@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tcpm@ietf.org, Ted Faber , 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, 9 Nov 2005, Joe Touch wrote: >> Simple ingress/egress filtering serves as a counter-measure for >> TCP-based attacks. But it does not serve as a counter-measure for >> ICMP-based ones. > > This depends on the paths, the filters, and the location of the > attacker. In some cases, it's easier to spoof a source address than the > address of an arbitrary router. I do not see how this holds. TCP RST requires spoofing the source address of the victim. It's equally easy to generate an ICMP error with source address of the victim (in the IP header), AND the the victim also in the encapsulated ICMP data. You don't need to spoof a router on the path, and you actually don't need to spoof at all if you aren't concerned about traceability. The only case where there may be a difference is if either the attacker or the victim is behind a firewall which drops all outgoing or incoming (respectively) ICMP messages -- even the valid ones. ... > Existence of cases where ICMP is easier than TCP does not preclude cases > where the converse is true. Could you please explain at least one concrete example of the converse? -- 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 Wed Nov 09 12:40:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtvX-0005bB-2L; Wed, 09 Nov 2005 12:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtvV-0005al-Fy for tcpm@megatron.ietf.org; Wed, 09 Nov 2005 12:40:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24897 for ; Wed, 9 Nov 2005 12:39:34 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZuBW-0003Sa-Uo for tcpm@ietf.org; Wed, 09 Nov 2005 12:56:37 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9HcrM10380; Wed, 9 Nov 2005 09:38:53 -0800 (PST) Message-ID: <4372342B.40600@isi.edu> Date: Wed, 09 Nov 2005 09:38:51 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> <4371B93E.5090700@isi.edu> In-Reply-To: X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: tcpm@ietf.org, Ted Faber , 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: , Content-Type: multipart/mixed; boundary="===============0458380805==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0458380805== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE4DBB8CAC4B00E83AA10F9DC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE4DBB8CAC4B00E83AA10F9DC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Wed, 9 Nov 2005, Joe Touch wrote: >>> Simple ingress/egress filtering serves as a counter-measure for >>> TCP-based attacks. But it does not serve as a counter-measure for >>> ICMP-based ones. >> >> This depends on the paths, the filters, and the location of the >> attacker. In some cases, it's easier to spoof a source address than th= e >> address of an arbitrary router. >=20 > I do not see how this holds. TCP RST requires spoofing the source > address of the victim. It's equally easy to generate an ICMP error wit= h > source address of the victim (in the IP header), AND the the victim als= o > in the encapsulated ICMP data. You don't need to spoof a router on the= > path, and you actually don't need to spoof at all if you aren't > concerned about traceability. >=20 > The only case where there may be a difference is if either the attacker= > or the victim is behind a firewall which drops all outgoing or incoming= > (respectively) ICMP messages -- even the valid ones. >=20 > ... >> Existence of cases where ICMP is easier than TCP does not preclude cas= es >> where the converse is true. >=20 > Could you please explain at least one concrete example of the converse?= The above one you gave (all ICMPs dropped) is good enough. JOe >=20 --------------enigE4DBB8CAC4B00E83AA10F9DC 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDcjQrE5f5cImnZrsRAv/uAJ4xC9HfWrmT0Bs34Nh+vLpNsgFWLQCg25ll XYWShXAt1oV1K/ajYC+sxTA= =GiBu -----END PGP SIGNATURE----- --------------enigE4DBB8CAC4B00E83AA10F9DC-- --===============0458380805== 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 --===============0458380805==-- From tcpm-bounces@ietf.org Wed Nov 09 13:56:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv7V-00016O-DG; Wed, 09 Nov 2005 13:56:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv7T-00016D-RS for tcpm@megatron.ietf.org; Wed, 09 Nov 2005 13:56:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00180 for ; Wed, 9 Nov 2005 13:56:00 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvNW-0005tI-V5 for tcpm@ietf.org; Wed, 09 Nov 2005 14:13:04 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9ItuM06073; Wed, 9 Nov 2005 10:55:56 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jA9ItuCS004530; Wed, 9 Nov 2005 10:55:56 -0800 (PST) (envelope-from faber) Date: Wed, 9 Nov 2005 10:55:56 -0800 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 Message-ID: <20051109185555.GC3181@hut.isi.edu> References: <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> <4371B93E.5090700@isi.edu> <4372342B.40600@isi.edu> Mime-Version: 1.0 In-Reply-To: <4372342B.40600@isi.edu> User-Agent: Mutt/1.4.2.1i 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: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tcpm@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============0648834840==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0648834840== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7gGkHNMELEOhSGF6" Content-Disposition: inline --7gGkHNMELEOhSGF6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 09, 2005 at 09:38:51AM -0800, Joe Touch wrote: >=20 >=20 > Pekka Savola wrote: > > On Wed, 9 Nov 2005, Joe Touch wrote: > >>> Simple ingress/egress filtering serves as a counter-measure for > >>> TCP-based attacks. But it does not serve as a counter-measure for > >>> ICMP-based ones. > >> > >> This depends on the paths, the filters, and the location of the > >> attacker. In some cases, it's easier to spoof a source address than the > >> address of an arbitrary router. > >=20 > > I do not see how this holds. TCP RST requires spoofing the source > > address of the victim. It's equally easy to generate an ICMP error with > > source address of the victim (in the IP header), AND the the victim also > > in the encapsulated ICMP data. You don't need to spoof a router on the > > path, and you actually don't need to spoof at all if you aren't > > concerned about traceability. > >=20 > > The only case where there may be a difference is if either the attacker > > or the victim is behind a firewall which drops all outgoing or incoming > > (respectively) ICMP messages -- even the valid ones. > >=20 > > ... > >> Existence of cases where ICMP is easier than TCP does not preclude cas= es > >> where the converse is true. > >=20 > > Could you please explain at least one concrete example of the converse? >=20 > The above one you gave (all ICMPs dropped) is good enough. Joe, can you just work the example in more detail? I can't help but notice that the shorter everyone's replies get, the longer the e-mail thread gets and the less actually gets said. It seems to me that's because people are each discussing what's in their own head. If there's a concrete case to discuss, please lay it out and we'll all be talking about the same thing. Thanks. --=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 --7gGkHNMELEOhSGF6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDckY7aUz3f+Zf+XsRAhQUAJ0YDf+F5tUzXpBwnN65gPpRtQwn5gCg+M61 L5t8zaFDEPO41/hgzjw7mtU= =zkRI -----END PGP SIGNATURE----- --7gGkHNMELEOhSGF6-- --===============0648834840== 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 --===============0648834840==-- From tcpm-bounces@ietf.org Wed Nov 09 14:11:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvMQ-0007ok-Qq; Wed, 09 Nov 2005 14:11:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvMP-0007oY-Nm for tcpm@megatron.ietf.org; Wed, 09 Nov 2005 14:11:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01482 for ; Wed, 9 Nov 2005 14:11:26 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvcT-0006RO-W3 for tcpm@ietf.org; Wed, 09 Nov 2005 14:28:30 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9JB7M10909; Wed, 9 Nov 2005 11:11:07 -0800 (PST) Message-ID: <437249CA.2080003@isi.edu> Date: Wed, 09 Nov 2005 11:11:06 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 References: <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> <4371B93E.5090700@isi.edu> <4372342B.40600@isi.edu> <20051109185555.GC3181@hut.isi.edu> In-Reply-To: <20051109185555.GC3181@hut.isi.edu> X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tcpm@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============1244776098==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1244776098== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE9AB6238F4767EAA8C2459AF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE9AB6238F4767EAA8C2459AF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Wed, Nov 09, 2005 at 09:38:51AM -0800, Joe Touch wrote: >> >> Pekka Savola wrote: >>> On Wed, 9 Nov 2005, Joe Touch wrote: >>>>> Simple ingress/egress filtering serves as a counter-measure for >>>>> TCP-based attacks. But it does not serve as a counter-measure for >>>>> ICMP-based ones. >>>> This depends on the paths, the filters, and the location of the >>>> attacker. In some cases, it's easier to spoof a source address than = the >>>> address of an arbitrary router. >>> I do not see how this holds. TCP RST requires spoofing the source >>> address of the victim. It's equally easy to generate an ICMP error w= ith >>> source address of the victim (in the IP header), AND the the victim a= lso >>> in the encapsulated ICMP data. You don't need to spoof a router on t= he >>> path, and you actually don't need to spoof at all if you aren't >>> concerned about traceability. >>> >>> The only case where there may be a difference is if either the attack= er >>> or the victim is behind a firewall which drops all outgoing or incomi= ng >>> (respectively) ICMP messages -- even the valid ones. >>> >>> ... >>>> Existence of cases where ICMP is easier than TCP does not preclude c= ases >>>> where the converse is true. >>> Could you please explain at least one concrete example of the convers= e? > >> The above one you gave (all ICMPs dropped) is good enough. >=20 > Joe, can you just work the example in more detail?=20 That doesn't seem useful; it's trivial: - all border routers drop ICMPs - it's now easier to attack with TCP spoofing than with ICMP That's the case Fernando provided. The case I had been considering was different, and allowed for some ICMPs to still get through: - border routers drop ICMPs except from 'blessed' router addresses, perhaps a list of 'authorized routers' somewhere - the attacker shares some property of the path to the endpoint being attacked that means the traffic can't be filtered (trivial case he's in the same domain as the one he's attacking, but other cases can occur depending on filter policy) Again, it's easier to spoof than to send an ICMP. Joe --------------enigE9AB6238F4767EAA8C2459AF 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDcknKE5f5cImnZrsRAsQEAJ9pHZujkd+tyTZ7z01sl4BXdpgcZwCgyXBm PcyIphRZ2tUSyiROHy1R3W0= =9caX -----END PGP SIGNATURE----- --------------enigE9AB6238F4767EAA8C2459AF-- --===============1244776098== 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 --===============1244776098==-- From tcpm-bounces@ietf.org Wed Nov 09 14:31:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvfi-0008RM-3w; Wed, 09 Nov 2005 14:31:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvfg-0008RD-Nx for tcpm@megatron.ietf.org; Wed, 09 Nov 2005 14:31:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03031 for ; Wed, 9 Nov 2005 14:31:21 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvvj-00078p-U1 for tcpm@ietf.org; Wed, 09 Nov 2005 14:48:25 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA9JVOX00314; Wed, 9 Nov 2005 21:31:24 +0200 Date: Wed, 9 Nov 2005 21:31:24 +0200 (EET) From: Pekka Savola To: Joe Touch Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 In-Reply-To: <437249CA.2080003@isi.edu> Message-ID: References: <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> <4371B93E.5090700@isi.edu> <4372342B.40600@isi.edu> <20051109185555.GC3181@hut.isi.edu> <437249CA.2080003@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tcpm@ietf.org, Ted Faber , 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, 9 Nov 2005, Joe Touch wrote: > That doesn't seem useful; it's trivial: > > - all border routers drop ICMPs > - it's now easier to attack with TCP spoofing than with ICMP "Trivial"? Could you provide some data, especially around "all"? (and possibly "easier") > The case I had been considering was different, and allowed for some > ICMPs to still get through: > > - border routers drop ICMPs except from > 'blessed' router addresses, perhaps a list of > 'authorized routers' somewhere Do you have data whether this kind of configuration actually exists somewhere? -- 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 Wed Nov 09 17:14:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZyD2-0004i6-9Y; Wed, 09 Nov 2005 17:14:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZyCz-0004hV-Uo for tcpm@megatron.ietf.org; Wed, 09 Nov 2005 17:14:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13964 for ; Wed, 9 Nov 2005 17:13:53 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZyT4-000414-Qr for tcpm@ietf.org; Wed, 09 Nov 2005 17:31:00 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9M08M13742; Wed, 9 Nov 2005 14:00:09 -0800 (PST) Message-ID: <43727164.9070107@isi.edu> Date: Wed, 09 Nov 2005 14:00:04 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 References: <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> <4371B93E.5090700@isi.edu> <4372342B.40600@isi.edu> <20051109185555.GC3181@hut.isi.edu> <437249CA.2080003@isi.edu> In-Reply-To: X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: tcpm@ietf.org, Ted Faber , 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: , Content-Type: multipart/mixed; boundary="===============2034475700==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2034475700== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8F23729086628621AAAEB2A7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8F23729086628621AAAEB2A7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Wed, 9 Nov 2005, Joe Touch wrote: >> That doesn't seem useful; it's trivial: >> >> - all border routers drop ICMPs >> - it's now easier to attack with TCP spoofing than with ICMP >=20 > "Trivial"? Could you provide some data, especially around "all"? (and > possibly "easier") Consider borders with firewalls that drop all ICMPs; I'm not proposing that all border routers on the planet do so, I'm proposing a case in which a domain is so configured. Now TCP attacks are possible, and ICMP attacks are not - thus 'easier' is defined as 'more possible than not at all'. >> The case I had been considering was different, and allowed for some >> ICMPs to still get through: >> >> - border routers drop ICMPs except from >> 'blessed' router addresses, perhaps a list of >> 'authorized routers' somewhere >=20 > Do you have data whether this kind of configuration actually exists > somewhere? The point of this thread was existence of legitimate configurations that are mistaken as attacks, including cases where TCP is preferred. Just because ICMP attacks are more likely doesn't mean, for example, that changing semantics and standards to close that 'preferred' door actually secures the house. That's the high-order point here, and why that needs to be discussed in at least the security considerations of this doc. Joe --------------enig8F23729086628621AAAEB2A7 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDcnFkE5f5cImnZrsRArQdAJwLtC9YwgsLpy20kvhCptnN1TIndwCgzi0H P8Hhv5SksK+RLS8fghZjNL8= =wDw4 -----END PGP SIGNATURE----- --------------enig8F23729086628621AAAEB2A7-- --===============2034475700== 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 --===============2034475700==-- From tcpm-bounces@ietf.org Wed Nov 09 18:09:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZz3w-0007vo-VG; Wed, 09 Nov 2005 18:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZz3w-0007vj-CV for tcpm@megatron.ietf.org; Wed, 09 Nov 2005 18:09:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16527 for ; Wed, 9 Nov 2005 18:08:35 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZzJz-0005L1-Bm for tcpm@ietf.org; Wed, 09 Nov 2005 18:25:42 -0500 Received: (qmail 16169 invoked from network); 9 Nov 2005 23:07:25 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 9 Nov 2005 23:07:25 -0000 Message-Id: <6.2.0.14.0.20051109145531.04126398@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 09 Nov 2005 15:08:09 -0800 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 In-Reply-To: <4371B93E.5090700@isi.edu> References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> <4371B93E.5090700@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 12:54 a.m. 09/11/2005, Joe Touch wrote: > > Simple ingress/egress filtering serves as a counter-measure for > > TCP-based attacks. But it does not serve as a counter-measure for > > ICMP-based ones. > >This depends on the paths, the filters, and the location of the >attacker. In some cases, it's easier to spoof a source address than the >address of an arbitrary router. Why do you think you need to spoof the IP address of a router? If anything, you need to spoof the values that are in the ICMP payload. Which is not where simple ingress/egress filters look at to decide whether to filter a packet or not. > > ICMP-based attacks have been used for ages. Even by script-kiddies, for > > taking over IRC channels. > > > > Guess why they didn't use TCP-based ones. > >Existence of cases where ICMP is easier than TCP does not preclude cases >where the converse is true. Can you please mention a few cases? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 09 19:16:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea07S-0001Re-BJ; Wed, 09 Nov 2005 19:16:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea07Q-0001RE-LO for tcpm@megatron.ietf.org; Wed, 09 Nov 2005 19:16:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20989 for ; Wed, 9 Nov 2005 19:16:17 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea0NW-0007F9-JC for tcpm@ietf.org; Wed, 09 Nov 2005 19:33:23 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA9Nk5M16782; Wed, 9 Nov 2005 15:46:05 -0800 (PST) Message-ID: <43728A3C.2080605@isi.edu> Date: Wed, 09 Nov 2005 15:46:04 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05 References: <436E7ABE.1000004@isi.edu> <6.2.0.14.0.20051106160757.0432ea98@localhost> <436F7C08.9020104@isi.edu> <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> <4371B93E.5090700@isi.edu> <6.2.0.14.0.20051109145531.04126398@localhost> In-Reply-To: <6.2.0.14.0.20051109145531.04126398@localhost> X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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="===============0060093226==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0060093226== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig95F8404316B4893130FC2F05" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig95F8404316B4893130FC2F05 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 12:54 a.m. 09/11/2005, Joe Touch wrote: >=20 >> > Simple ingress/egress filtering serves as a counter-measure for >> > TCP-based attacks. But it does not serve as a counter-measure for >> > ICMP-based ones. >> >> This depends on the paths, the filters, and the location of the >> attacker. In some cases, it's easier to spoof a source address than th= e >> address of an arbitrary router. >=20 > Why do you think you need to spoof the IP address of a router? >=20 > If anything, you need to spoof the values that are in the ICMP payload.= > Which is not where simple ingress/egress filters look at to decide > whether to filter a packet or not. >=20 >=20 >> > ICMP-based attacks have been used for ages. Even by script-kiddies, = for >> > taking over IRC channels. >> > >> > Guess why they didn't use TCP-based ones. >> >> Existence of cases where ICMP is easier than TCP does not preclude cas= es >> where the converse is true. >=20 > Can you please mention a few cases? You already did - where ICMP is blocked. One is more than sufficient. Joe --------------enig95F8404316B4893130FC2F05 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDcoo8E5f5cImnZrsRAnvMAJ9FIoVxdCk0ugv4p1v0JtJ9oohgVwCgs6Gi 6+lhRvaFSCRTIx+gZOGzMpw= =tW1a -----END PGP SIGNATURE----- --------------enig95F8404316B4893130FC2F05-- --===============0060093226== 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 --===============0060093226==-- From tcpm-bounces@ietf.org Wed Nov 09 20:12:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea0zI-0005Zw-6G; Wed, 09 Nov 2005 20:12:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea0zG-0005Zq-L5 for tcpm@megatron.ietf.org; Wed, 09 Nov 2005 20:12:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23872 for ; Wed, 9 Nov 2005 20:11:55 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea1FL-0000CC-8O for tcpm@ietf.org; Wed, 09 Nov 2005 20:29:02 -0500 Received: (qmail 11851 invoked from network); 10 Nov 2005 01:10:48 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 10 Nov 2005 01:10:48 -0000 Message-Id: <6.2.0.14.0.20051109165222.0405aa38@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 09 Nov 2005 17:11:25 -0800 To: Joe Touch , Pekka Savola From: Fernando Gont Subject: Summing-up (Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05) In-Reply-To: <43727164.9070107@isi.edu> References: <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> <4371B93E.5090700@isi.edu> <4372342B.40600@isi.edu> <20051109185555.GC3181@hut.isi.edu> <437249CA.2080003@isi.edu> <43727164.9070107@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 02:00 p.m. 09/11/2005, Joe Touch wrote: >Consider borders with firewalls that drop all ICMPs; I'm not proposing >that all border routers on the planet do so, I'm proposing a case in >which a domain is so configured. > >Now TCP attacks are possible, and ICMP attacks are not - thus 'easier' >is defined as 'more possible than not at all'. C'mon Joe, that's far from being realistic. What's the next thing you will object? > > Do you have data whether this kind of configuration actually exists > > somewhere? > >The point of this thread was existence of legitimate configurations that >are mistaken as attacks, including cases where TCP is preferred. Do you know which is the only case in which a TCP-based connection reset attack is preferred? In those scenarios such as ones with BSD-derived or Mentat-derived implementations, in which you will not be able to perform ICMP-based ones because those systems already implement draft-gont-tcm-icmp-attacks-05.txt. I have built some tools for these attacks. You have them available at http://www.gont.com.ar/tools/icmp-attacks/index.html . Get some unpatched Windows system (IIRC, by now they are already implementing draft-gont). Try to perform the ICMP-based attacks, and try to perform the TCP-based ones. And tell me which one was easier to perform. >Just because ICMP attacks are more likely doesn't mean, for example, >that changing semantics and standards to close that 'preferred' door >actually secures the house. That's the high-order point here, and why >that needs to be discussed in at least the security considerations of >this doc. Let me try to be super-clear, in case I have not been: My draft is about mitigating ICMP based ones. Simply that. And it impoves TCP's robustness. At least in the last couple of days you have objected my draft because it doesn't do things it is NOT supposed to do. By now, you have argued against: * hard errors -> soft errors * TCP SEQ check being completely unacceptable * Draft title * Draft focus * That the draft does not address attacks it has never been supposed to address * That it is easier to perform a TCP-based attack than an ICMP-based ones. * You have argued that even if there are still working paths to get to the destination host, you should abort a connection upon receipt of a so-called ICMP hard error. IMHO, you're arguments tend to kill TCP's robustness. But, given that this type of discussion has lasted for more than one year, I don't aim to change your mind. I do recommend that you raise your issues in the TCPM WG meeting, probably cross-post them to the tsvwg mailing-list, and also post them to security mailing lists such as bugtraq and full-disclosure. And convince the 50+ vendors that have already implemented draft-gont to unpatch their systems, to make them look like honepots to script kiddies. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 09 20:34:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea1KM-00063w-Eh; Wed, 09 Nov 2005 20:34:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea1KK-00062K-4R for tcpm@megatron.ietf.org; Wed, 09 Nov 2005 20:34:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24876 for ; Wed, 9 Nov 2005 20:33:40 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea1aN-0000jo-FE for tcpm@ietf.org; Wed, 09 Nov 2005 20:50:48 -0500 Received: (qmail 21417 invoked from network); 10 Nov 2005 01:32:49 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 10 Nov 2005 01:32:49 -0000 Message-Id: <6.2.0.14.0.20051109173124.04b30d48@pop.softhome.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 09 Nov 2005 17:33:39 -0800 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.2 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [tcpm] Feedback/support from the NetBSD community (Fwd: Re: ICMP attacks draft) 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Folks, NetBSD already implements all the counter-measures proposed in draft-gont-tcpm-icmp-attacks-05.txt. I'm forwarding an e-mail from one of the NetBSD guys. >From: christos@zoulas.com (Christos Zoulas) >Date: Wed, 9 Nov 2005 18:05:40 -0500 >Organization: Astron Software >X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) >To: Fernando Gont >Subject: Re: ICMP attacks draft > >To the TCPM group, > >Dear Sirs, > >I have implemented Fernando Gont's patches in the NetBSD TCP/IP >stack on July 2005 and I've been running many production machines >on the Internet with these changes without any adverse effects. >Although I have not experienced any MTU related, or ICMP Source >Quench attacks (that I know of), I believe that Fernando's analysis >is correct and his countermeasures are simple, easy to implement, >and should be effective to defend against the attacks described. > >Best Regards, > >Christos Zoulas -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 09 20:39:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea1P8-0006uH-Le; Wed, 09 Nov 2005 20:39:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea1P7-0006uC-Iu for tcpm@megatron.ietf.org; Wed, 09 Nov 2005 20:39:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25107 for ; Wed, 9 Nov 2005 20:38:38 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea1fC-0000qy-4r for tcpm@ietf.org; Wed, 09 Nov 2005 20:55:45 -0500 Received: (qmail 21988 invoked from network); 10 Nov 2005 01:37:50 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 10 Nov 2005 01:37:50 -0000 Message-Id: <6.2.0.14.0.20051109173422.04b2b458@pop.softhome.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 09 Nov 2005 17:38:23 -0800 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [tcpm] Feedback/support from the FreeBSD community (Fwd: Re: Moving the ICMP attacks draft forward) 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Folks, I'm forwarding an e-mail from FreeBSD's Andre Oppermann. FreeBSD implements all the counter-measures proposed in drft-gont-tcpm-icmp-attacks-05.txt, except for the one for the PMTUD, which they implement partialy. However, they are planning to implement it. >Date: Tue, 08 Nov 2005 23:48:26 +0100 >From: Andre Oppermann >X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) >X-Accept-Language: en >To: Fernando Gont >Subject: Re: Moving the ICMP attacks draft forward > >Hi Fernando, > >FreeBSD has implemented the sequence number check for all ICMP messages >that received in response to some TCP segment. Source quench messages >are ignored completely. PMTU messages that have made it through the >seqnum check are acted upon if the newly proposed MTU is greater or >equal to 256 bytes. For those without an MTU proposal we step down >by one over a number of common MTUs with the lower bound of 256 bytes. >This approach keeps a sufficient high segment overhead versus payload >ratio. > >For the moment we think this is sufficient. However in the longer >term we want to implement the approach described in your draft. > >I hope this helps with your persuation of the TCPM WG to promote >your draft to RFC status. > >And I want, on behalf of the FreeBSD team and personally, to thank >you for raising, documenting and proposing workarounds to these TCP >issues. > >Best regards >-- >Andre Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 10 10:49:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaEgX-0000rU-5r; Thu, 10 Nov 2005 10:49:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaEgV-0000rP-CX for tcpm@megatron.ietf.org; Thu, 10 Nov 2005 10:49:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11775 for ; Thu, 10 Nov 2005 10:49:26 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaEwh-0005zv-8s for tcpm@ietf.org; Thu, 10 Nov 2005 11:06:42 -0500 Received: from jurassic.eng.sun.com ([129.146.228.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jAAFnoD7027695 for ; Thu, 10 Nov 2005 08:49:50 -0700 (MST) Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAAFnmbp212143 for ; Thu, 10 Nov 2005 07:49:49 -0800 (PST) Message-ID: <43736C1A.6040501@sun.com> Date: Thu, 10 Nov 2005 07:49:46 -0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: Summing-up (Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05) References: <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> <4371B93E.5090700@isi.edu> <4372342B.40600@isi.edu> <20051109185555.GC3181@hut.isi.edu> <437249CA.2080003@isi.edu> <43727164.9070107@isi.edu> <6.2.0.14.0.20051109165222.0405aa38@localhost> In-Reply-To: <6.2.0.14.0.20051109165222.0405aa38@localhost> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > I do recommend that you raise your issues in the TCPM WG meeting, > probably cross-post them to the tsvwg mailing-list, and also post them > to security mailing lists such as bugtraq and full-disclosure. > > And convince the 50+ vendors that have already implemented draft-gont to > unpatch their systems, to make them look like honepots to script kiddies. There is no question that most, if not all, vendors have implemented all or most of the mechanisms described in this draft. Unless the TCPM WG really wants to have the IETF "documented" TCP standard to deviate from real world running code, I'd suggest the WG to adopt this draft as a WG document and decide which track it is suitable for. -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 10 11:47:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFaV-0002dC-Im; Thu, 10 Nov 2005 11:47:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFaU-0002d7-CS for tcpm@megatron.ietf.org; Thu, 10 Nov 2005 11:47:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15819 for ; Thu, 10 Nov 2005 11:47:16 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaFqi-0007oV-Es for tcpm@ietf.org; Thu, 10 Nov 2005 12:04:32 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAAGk1E28509; Thu, 10 Nov 2005 08:46:02 -0800 (PST) Message-ID: <43737940.6010706@isi.edu> Date: Thu, 10 Nov 2005 08:45:52 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Fernando Gont Subject: Re: Summing-up (Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05) References: <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> <4371B93E.5090700@isi.edu> <4372342B.40600@isi.edu> <20051109185555.GC3181@hut.isi.edu> <437249CA.2080003@isi.edu> <43727164.9070107@isi.edu> <6.2.0.14.0.20051109165222.0405aa38@localhost> In-Reply-To: <6.2.0.14.0.20051109165222.0405aa38@localhost> X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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="===============1138576236==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1138576236== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig92419D7F67B996B2B45A55CF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig92419D7F67B996B2B45A55CF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 02:00 p.m. 09/11/2005, Joe Touch wrote: >=20 >> Consider borders with firewalls that drop all ICMPs; I'm not proposing= >> that all border routers on the planet do so, I'm proposing a case in >> which a domain is so configured. >> >> Now TCP attacks are possible, and ICMP attacks are not - thus 'easier'= >> is defined as 'more possible than not at all'. >=20 > C'mon Joe, that's far from being realistic. What's the next thing you > will object? To this post ;-) =2E.. >> Just because ICMP attacks are more likely doesn't mean, for example, >> that changing semantics and standards to close that 'preferred' door >> actually secures the house. That's the high-order point here, and why >> that needs to be discussed in at least the security considerations of >> this doc. >=20 > Let me try to be super-clear, in case I have not been: > My draft is about mitigating ICMP based ones. Simply that. And it > impoves TCP's robustness. Here's MY summary: 1) the doc puts forth validity checks as security protections 2) the validity checks are incorrect Appendix C concerns need to be addressed where the checks are discussed, as a requisite precursor to checks of ICMPs from end-hosts 3) the doc indirectly protects from blind attacks but not non-blind or TCP attacks this needs to be highlighted very early, e.g., in the abstract note that non-blind, which I have referred to as on-path, is NOT the same as MITM; MITM have the ability not only to snoop but to selectively remove traffic. On path do not remove traffic. I've made my case; the WG can decide how to move forward. =2E.. > I do recommend that you raise your issues in the TCPM WG meeting, > probably cross-post them to the tsvwg mailing-list, and also post them > to security mailing lists such as bugtraq and full-disclosure. Certainly. > And convince the 50+ vendors that have already implemented draft-gont t= o > unpatch their systems, to make them look like honepots to script kiddie= s. Hmmm - like TCP-probs (RFC2525) did? We'll just do another round of that in a few years entitled "hazards of non-security security solutions". Vendors aren't the measure of the IETF; we regularly need to remind them of specs and the unforseen effects of changing them to address immediate or local concerns without considering the big picture and long-term. Joe --------------enig92419D7F67B996B2B45A55CF 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDc3lAE5f5cImnZrsRApSLAKCUNY2WbF1RDt2uq1ykppsUMQAnLwCgoqpk zyJZyqTNtsmotC8UcrbeeZs= =5GBT -----END PGP SIGNATURE----- --------------enig92419D7F67B996B2B45A55CF-- --===============1138576236== 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 --===============1138576236==-- From tcpm-bounces@ietf.org Thu Nov 10 11:52:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFel-00045E-Nf; Thu, 10 Nov 2005 11:52:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFek-000459-B5 for tcpm@megatron.ietf.org; Thu, 10 Nov 2005 11:52:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16045 for ; Thu, 10 Nov 2005 11:51:41 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaFuy-0007vs-Vw for tcpm@ietf.org; Thu, 10 Nov 2005 12:08:58 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAAGpDE00596; Thu, 10 Nov 2005 08:51:13 -0800 (PST) Message-ID: <43737A7F.4020109@isi.edu> Date: Thu, 10 Nov 2005 08:51:11 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Kacheong Poon Subject: Re: Summing-up (Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05) References: <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> <4371B93E.5090700@isi.edu> <4372342B.40600@isi.edu> <20051109185555.GC3181@hut.isi.edu> <437249CA.2080003@isi.edu> <43727164.9070107@isi.edu> <6.2.0.14.0.20051109165222.0405aa38@localhost> <43736C1A.6040501@sun.com> In-Reply-To: <43736C1A.6040501@sun.com> X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) 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: , Content-Type: multipart/mixed; boundary="===============1448107922==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1448107922== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2DE554743D11F84CA54C3220" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2DE554743D11F84CA54C3220 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kacheong Poon wrote: > Fernando Gont wrote: >=20 >> I do recommend that you raise your issues in the TCPM WG meeting, >> probably cross-post them to the tsvwg mailing-list, and also post them= >> to security mailing lists such as bugtraq and full-disclosure. >> >> And convince the 50+ vendors that have already implemented draft-gont = to >> unpatch their systems, to make them look like honepots to script kiddi= es. >=20 > There is no question that most, if not all, vendors have > implemented all or most of the mechanisms described in this > draft. Unless the TCPM WG really wants to have the IETF > "documented" TCP standard to deviate from real world running > code, I'd suggest the WG to adopt this draft as a WG document > and decide which track it is suitable for. See my other post about TCP-probs. This WG should decide the utility and necessity of this code of its own merit; this is not a vendor popularity contest. Joe --------------enig2DE554743D11F84CA54C3220 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDc3p/E5f5cImnZrsRAs7KAJ49qedzjv6L7fSjYj4pD8b/cz6tXQCeKOrW 7Qftj1Vua1Fueaglj17SmZQ= =3jS7 -----END PGP SIGNATURE----- --------------enig2DE554743D11F84CA54C3220-- --===============1448107922== 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 --===============1448107922==-- From tcpm-bounces@ietf.org Thu Nov 10 11:55:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFiM-0005Dj-2A; Thu, 10 Nov 2005 11:55:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFiJ-0005Cb-Uu for tcpm@megatron.ietf.org; Thu, 10 Nov 2005 11:55:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16289 for ; Thu, 10 Nov 2005 11:55:22 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaFyY-000821-Pc for tcpm@ietf.org; Thu, 10 Nov 2005 12:12:39 -0500 Received: from [209.52.104.180] (pp104-180.bctel.ca [209.52.104.180]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAAGroE01372; Thu, 10 Nov 2005 08:53:51 -0800 (PST) Message-ID: <43737B19.2040609@isi.edu> Date: Thu, 10 Nov 2005 08:53:45 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Feedback/support from the FreeBSD community (Fwd: Re: Moving the ICMP attacks draft forward) References: <6.2.0.14.0.20051109173422.04b2b458@pop.softhome.net> In-Reply-To: <6.2.0.14.0.20051109173422.04b2b458@pop.softhome.net> X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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="===============1638601130==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1638601130== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8CFA7FB8263EBF0F14D9FB72" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8CFA7FB8263EBF0F14D9FB72 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable These are the same ones who put in the RST mods - with a note that it violates TCP specs - even though they don't help general users at all. We're trying right now to undo that, and have the default be OFF at least UNTIL the WG makes a decision on how to proceed. Note - I have NOT asserted that the ICMP code is bad, just that the doc is written in a misleading way. The fact that vendors are running headlong to adopt it can be taken as evidence that this misleading wording has had a "fire in a crowded room" effect. Joe Fernando Gont wrote: > Folks, >=20 > I'm forwarding an e-mail from FreeBSD's Andre Oppermann. FreeBSD > implements all the counter-measures proposed in > drft-gont-tcpm-icmp-attacks-05.txt, except for the one for the PMTUD, > which they implement partialy. However, they are planning to implement = it. >=20 >=20 >> Date: Tue, 08 Nov 2005 23:48:26 +0100 >> From: Andre Oppermann >> X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) >> X-Accept-Language: en >> To: Fernando Gont >> Subject: Re: Moving the ICMP attacks draft forward >> >> Hi Fernando, >> >> FreeBSD has implemented the sequence number check for all ICMP message= s >> that received in response to some TCP segment. Source quench messages= >> are ignored completely. PMTU messages that have made it through the >> seqnum check are acted upon if the newly proposed MTU is greater or >> equal to 256 bytes. For those without an MTU proposal we step down >> by one over a number of common MTUs with the lower bound of 256 bytes.= >> This approach keeps a sufficient high segment overhead versus payload >> ratio. >> >> For the moment we think this is sufficient. However in the longer >> term we want to implement the approach described in your draft. >> >> I hope this helps with your persuation of the TCPM WG to promote >> your draft to RFC status. >> >> And I want, on behalf of the FreeBSD team and personally, to thank >> you for raising, documenting and proposing workarounds to these TCP >> issues. >> >> Best regards >> --=20 >> Andre >=20 > Kindest regards, >=20 > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --------------enig8CFA7FB8263EBF0F14D9FB72 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDc3sZE5f5cImnZrsRAkklAJ9hep+OXf/m5nSC/t/12QSc6b9XhwCg8lj8 c28hnRKgbpI6/FdgXYGfMR4= =ExWd -----END PGP SIGNATURE----- --------------enig8CFA7FB8263EBF0F14D9FB72-- --===============1638601130== 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 --===============1638601130==-- From tcpm-bounces@ietf.org Thu Nov 10 20:11:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaNS4-0000vW-57; Thu, 10 Nov 2005 20:11:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaNS3-0000vR-1i for tcpm@megatron.ietf.org; Thu, 10 Nov 2005 20:11:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29684 for ; Thu, 10 Nov 2005 20:11:07 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaNiM-0002MY-5u for tcpm@ietf.org; Thu, 10 Nov 2005 20:28:27 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by mx2.foretec.com with esmtp (Exim 4.24) id 1EaNNK-0005ME-Ef for tcpm@ietf.org; Thu, 10 Nov 2005 20:06:42 -0500 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jAB106IB025688; Thu, 10 Nov 2005 20:00:06 -0500 (EST) Received: from [128.89.80.73] (lion.bbn.com [128.89.80.73]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id jAB106210044; Thu, 10 Nov 2005 20:00:06 -0500 (EST) Message-ID: <4373ED15.1060102@bbn.com> Date: Thu, 10 Nov 2005 20:00:05 -0500 From: "Armando L. Caro, Jr." User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050819) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kacheong Poon Subject: Re: Summing-up (Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05) References: <6.2.0.14.0.20051107151117.01f2b558@localhost> <43702BB2.4000407@isi.edu> <20051108171941.GA86519@hut.isi.edu> <6.2.0.14.0.20051108163048.0388f238@localhost> <43715A72.9080109@isi.edu> <6.2.0.14.0.20051108192423.038dbff8@localhost> <4371B93E.5090700@isi.edu> <4372342B.40600@isi.edu> <20051109185555.GC3181@hut.isi.edu> <437249CA.2080003@isi.edu> <43727164.9070107@isi.edu> <6.2.0.14.0.20051109165222.0405aa38@localhost> <43736C1A.6040501@sun.com> In-Reply-To: <43736C1A.6040501@sun.com> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Kacheong Poon wrote: > There is no question that most, if not all, vendors have > implemented all or most of the mechanisms described in this > draft. Unless the TCPM WG really wants to have the IETF > "documented" TCP standard to deviate from real world running > code, I'd suggest the WG to adopt this draft as a WG document > and decide which track it is suitable for. I thought the IETF was suppose to be the standards body, not some collection of vendors. I don't think we should alter the role of the IETF to simply document and recommend mechanisms that are popular with vendors. IMHO, the IETF should make recommendations independently of how popular they are with vendors. -- Armando www.armandocaro.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 10 20:54:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaO7a-0006z8-HO; Thu, 10 Nov 2005 20:54:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaO7Y-0006wa-FQ for tcpm@megatron.ietf.org; Thu, 10 Nov 2005 20:54:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02396 for ; Thu, 10 Nov 2005 20:53:59 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaONr-0003by-3A for tcpm@ietf.org; Thu, 10 Nov 2005 21:11:20 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAB1nFUW028660; Fri, 11 Nov 2005 03:49:15 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 03:49:14 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 03:49:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summing-up (Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05) Date: Fri, 11 Nov 2005 03:49:09 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D015CB46B@esebe100.NOE.Nokia.com> Thread-Topic: Summing-up (Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05) Thread-Index: AcXmXYDhTxYc+9rtTIiKRMPVBbSAywABD2Qg To: , X-OriginalArrivalTime: 11 Nov 2005 01:49:14.0005 (UTC) FILETIME=[1E55CC50:01C5E662] X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi all, >Kacheong Poon wrote: >> There is no question that most, if not all, vendors have implemented=20 >> all or most of the mechanisms described in this draft. Unless the=20 >> TCPM WG really wants to have the IETF "documented" TCP standard to=20 >> deviate from real world running code, I'd suggest the WG to=20 >adopt this=20 >> draft as a WG document and decide which track it is suitable for. > >I thought the IETF was suppose to be the standards body, not=20 >some collection of vendors. I don't think we should alter the=20 >role of the IETF to simply document and recommend mechanisms=20 >that are popular with vendors. IMHO, the IETF should make=20 >recommendations independently of how popular they are with vendors. I've been just lurking on this thread - but I have a different take. I think the IETF should document what people are doing - that way at least implementors know what common code bases are doing. =20 However, IETF Standards should document what we think is the right thing to do. If we were to document this draft as an RFC, then we should probably put some cautionary words in and maybe a forward pointer to what we consider the right thing to do is. John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 11 11:26:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EabjS-0006MZ-S3; Fri, 11 Nov 2005 11:26:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EabjR-0006MS-Gr for tcpm@megatron.ietf.org; Fri, 11 Nov 2005 11:26:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16951 for ; Fri, 11 Nov 2005 11:26:00 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eabzs-0002Zu-N7 for tcpm@ietf.org; Fri, 11 Nov 2005 11:43:29 -0500 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jABGQEIB021656; Fri, 11 Nov 2005 11:26:14 -0500 (EST) Received: from [128.89.80.73] (lion.bbn.com [128.89.80.73]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id jABGQE202246; Fri, 11 Nov 2005 11:26:14 -0500 (EST) Message-ID: <4374C626.8070203@bbn.com> Date: Fri, 11 Nov 2005 11:26:14 -0500 From: "Armando L. Caro, Jr." User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050819) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: Summing-up (Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05) References: <1AA39B75171A7144A73216AED1D7478D015CB46B@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D015CB46B@esebe100.NOE.Nokia.com> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, kacheong.poon@sun.com 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org john.loughney@nokia.com wrote: > I've been just lurking on this thread - but I have a different take. > I think the IETF should document what people are doing - that way > at least implementors know what common code bases are doing. Oh, I didn't mean to say that the IETF shouldn't document common code bases. I just meant that the IETF shouldn't recommend mechanisms because they are common. So, I'm agreeing with what you say below: > However, IETF Standards should document what we think is the right > thing to do. If we were to document this draft as an RFC, then > we should probably put some cautionary words in and maybe a forward > pointer to what we consider the right thing to do is. -- Armando www.armandocaro.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 11 11:59:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EacFH-0007I9-BB; Fri, 11 Nov 2005 11:59:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EacFG-0007Hj-8z for tcpm@megatron.ietf.org; Fri, 11 Nov 2005 11:59:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19606 for ; Fri, 11 Nov 2005 11:58:50 -0500 (EST) Received: from out001.apptix.savvis.net ([216.91.32.44] helo=s228130hz1ew03.apptix-01.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EacVf-0004Cy-LT for tcpm@ietf.org; Fri, 11 Nov 2005 12:16:20 -0500 Received: from s228130hz1ew08.apptix-01.savvis.net ([10.146.4.8]) by s228130hz1ew03.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 11 Nov 2005 10:59:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summing-up (Re: [tcpm] comments ondraft-gont-tcpm-icmp-attacks-05) Date: Fri, 11 Nov 2005 10:59:05 -0600 Message-ID: Thread-Topic: Summing-up (Re: [tcpm] comments ondraft-gont-tcpm-icmp-attacks-05) Thread-Index: AcXmXYDhTxYc+9rtTIiKRMPVBbSAywABD2QgAB+9+BA= From: "Schliesser, Benson" To: , , X-OriginalArrivalTime: 11 Nov 2005 16:59:07.0397 (UTC) FILETIME=[3A885350:01C5E6E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > IETF Standards should document what we think is the right > thing to do. I agree with this clearly. But one might argue that consensus of vendors and of users (i.e. providers) is a strong indicator of what is "right". Of course, sometimes it might instead be mass hallucination / mob mentality... *shrug* -Benson _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 14 16:25:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EblpJ-0002i2-KS; Mon, 14 Nov 2005 16:25:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EblpH-0002hh-Rv for tcpm@megatron.ietf.org; Mon, 14 Nov 2005 16:25:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02196 for ; Mon, 14 Nov 2005 16:24:47 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebm6N-0007aQ-99 for tcpm@ietf.org; Mon, 14 Nov 2005 16:43:00 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAELOkE02055 for ; Mon, 14 Nov 2005 13:24:46 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jAELOkJU020807 for tcpm@ietf.org; Mon, 14 Nov 2005 13:24:46 -0800 (PST) (envelope-from faber) Date: Mon, 14 Nov 2005 13:24:46 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20051114212446.GB47694@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.1i 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: 52e1467c2184c31006318542db5614d5 Subject: [tcpm] draft minutes posted 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="===============0861854067==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0861854067== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R3G7APHDIzY6R/pk" Content-Disposition: inline --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable http://www3.ietf.org/proceedings/05nov/minutes/tcpm.txt Please have a look at the minutes above and make sure it agrees with your memory of the meeting, especiall if you're mentioned by name. We're still missing a couple names, so feel free to let us know who you are. Thanks! --=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 --R3G7APHDIzY6R/pk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDeQCdaUz3f+Zf+XsRAiSTAJ42MwdAOs1pCYohUHRwKEh1nwMd1gCgzIiI XDiiKB0S3We5FgZ53DE/Z40= =vvei -----END PGP SIGNATURE----- --R3G7APHDIzY6R/pk-- --===============0861854067== 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 --===============0861854067==-- From tcpm-bounces@ietf.org Tue Nov 15 04:43:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbxLL-0008IL-T1; Tue, 15 Nov 2005 04:43:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbxLK-0008HN-1H for tcpm@megatron.ietf.org; Tue, 15 Nov 2005 04:43:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13888 for ; Tue, 15 Nov 2005 04:42:37 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbxcV-0006KN-QF for tcpm@ietf.org; Tue, 15 Nov 2005 05:00:57 -0500 Received: from [10.0.1.42] (maxp25.dialup.abdn.ac.uk [139.133.201.184]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id jAF9g472023095 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 15 Nov 2005 09:42:17 GMT User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 12 Nov 2005 17:30:28 +0000 From: Gorry Fairhurst To: , Lars Eggert , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, Ted Faber , "mallman@icir.org" Subject: [tcpm] draft-ietf-tcpm-tcp-uto-02 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The authors requested a review of the UTO mechanism. First my comments on the case for the method: 1) One major problem with this document is that it is hard to see what it is about, until you are well into the document. If I understand correctly, it is about a TCP Option for a receiver to request a sender to alter the time interval it will wait for a data segment to be acknowledged. 2) I don't yet see a compelling reason why this has to be negotiated at the TCP-layer. This needs to be made clear. The new method does not completely relieve the need for new code - Applications still need to add (some) code to use the new socket option. 3) If I understand, the mechanism is also per-direction of data transfer - that is there is no *necessity* for both end hosts to agree on the same values - although there are cases where they may both wish to (e.g.) increase the default. 4) My biggest worry that the current mechanism allows a remote party to alter the behaviour of a sender, without the prior consent of the host application. This seems wrong. I suggest it is important to consider whether this is "sane" - it needs thought. On the other hand, if the application calls-down the socket API saying this is allowed, then this is fine, and I would have no problems on this point. -------- Now comments on the protocol: 1) The wording describes sending the option in either/both the SYN v. established states. The protocol should be made clearer about this. If an end-host SENDS the option in a SYN packet, is it expected in the SYN-ACK? - One thing that I think needs thought is that in the currently defined method the Option in a SYN indicates "I may tell you that I wish to use a different UTO" - In fact the exact opposite is much more useful tgo the remote party: A SYN packet that carries an option saying "MY UTO is XXXX, you may change it". 2) A separate point, relating to options is that normal TCP behaviour REQUIRES an option to be present in the SYN to use it later. Is it REQUIRED to send this option in the SYN packet to be allowed to later use this once the session is established? 3) [anchor3]. This (the case for other timer changes) needs explained, if the WG does need to define more than a UTO and this is also needed let's do it in a consistent way (in this document, or decide not to). - I believe the decision needs to be made! 4) Too low a UTO can be VERY harmful to the network service. I believe it is very important to establish and define a sensible minimal value. All to many times applications developers write and test code in a LAN environment and only later deploy in the general Internet. We should not provide another opportunity for people to use TCP in cute ways that will break on arbitrary Internet paths! I think the minimum UTO must be REQUIRED. 5) I really feel uneasy about the idea of responding to a UTO option with another UTO option. This seems bad protocol design, and should at least be damped by imposing a minimum time before the response can be sent. Why do this? - I change my end, I request you to change yours. Is that not it done? I think that we can not afford for an incompatibility throwing packets backwards and forwards for ever, if that means defining another TCP Option, to inform of the change, then that needs to be thought about. 6) Are there situations in which you wish to allow the UTO to be reduced once the session has started. Allowing reduction of the UTO below the actual PRTT (whatever that means in practice) provides a DOS vulnerability. Another thing to note here, if I understand, is that reducing the UTO may immediately cause the session to close (if data was unacknowledged). 7) Are there any interoperability issues with NATs/Middleboxes when this is included on a SYN packet? Best wishes, Gorry Fairhurst P.S. One way to fix the Min UTO problem would be to set the units of measure as minutes .... ;-) ---- Some NiTs, /on a satellite/on a non-geostationary satellite/ - All satellites orbit, but the vast majority used for telecoms take an orbit that is goeostationary. /This document specifies.../ IMHO, this should come at the start, and would help clarify what the I-D is about. I do not see the necessity of the following refs: [SCHUETZ-THESIS] [SCHUETZ-CCR] [DRIVE-THRU]. There check the use of SHOULD and MUST in capitals [RFC2119]. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 16 13:29:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcS2D-0006ps-H4; Wed, 16 Nov 2005 13:29:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcS2C-0006pf-2D for tcpm@megatron.ietf.org; Wed, 16 Nov 2005 13:29:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15463 for ; Wed, 16 Nov 2005 13:28:53 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcSJe-0003TN-QS for tcpm@ietf.org; Wed, 16 Nov 2005 13:47:32 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAGIShE05197 for ; Wed, 16 Nov 2005 10:28:43 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jAGIShMV013911 for tcpm@ietf.org; Wed, 16 Nov 2005 10:28:43 -0800 (PST) (envelope-from faber) Date: Wed, 16 Nov 2005 10:28:43 -0800 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] draft minutes posted Message-ID: <20051116182842.GG4420@hut.isi.edu> References: <20051114212446.GB47694@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20051114212446.GB47694@hut.isi.edu> User-Agent: Mutt/1.4.2.1i 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: b19722fc8d3865b147c75ae2495625f2 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="===============1399629794==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1399629794== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0qt3EE9wi45a2ZFX" Content-Disposition: inline --0qt3EE9wi45a2ZFX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 14, 2005 at 01:24:46PM -0800, Ted Faber wrote: > http://www3.ietf.org/proceedings/05nov/minutes/tcpm.txt I've just posted a new version including feedback from a few and a pass through ispell (d'oh!). Probably best to try this version before sending me spelling errors. :-) --=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 --0qt3EE9wi45a2ZFX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDe3paaUz3f+Zf+XsRAlJEAKDmKWaQJwxLkYOG6YzEqwPnFMTu8gCcDVGo iL0UHXnw6v1yt5wwah7Dymg= =S5ft -----END PGP SIGNATURE----- --0qt3EE9wi45a2ZFX-- --===============1399629794== 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 --===============1399629794==-- From tcpm-bounces@ietf.org Thu Nov 17 17:45:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcsV4-0006HP-ET; Thu, 17 Nov 2005 17:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcsV2-0006HB-PH for tcpm@megatron.ietf.org; Thu, 17 Nov 2005 17:45:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01670 for ; Thu, 17 Nov 2005 17:44:26 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecsmk-0005vX-MM for tcpm@ietf.org; Thu, 17 Nov 2005 18:03:20 -0500 Received: from [70.209.253.17] (17.sub-70-209-253.myvzw.com [70.209.253.17]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAHMiLE07684; Thu, 17 Nov 2005 14:44:22 -0800 (PST) Message-ID: <437D07BE.5090504@isi.edu> Date: Thu, 17 Nov 2005 14:44:14 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: "'tcpm@ietf.org'" X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [tcpm] FYI - some preliminary perf comparison of MD5 vs. SHA-1 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="===============1021011986==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1021011986== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig74F6E9D63269D1A2829A1D5D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig74F6E9D63269D1A2829A1D5D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, I noted some comparative performance of SHA1 and MD5 at the meeting in Vancouver; here are some measurements made on a FreeBSD 5.4 PC using IPsec transport mode. I can post the machine specifics if they're useful, but the key is that software SHA1 is quite a bit slower than MD5.' Both are HMACs of 96 bits, FYI. TCP No crypt 529 Mb/s hmac-md5 228 Mb/s hmac-sha1 146 Mb/s Note that SHA1 is big-endian and MD5 is little-endian; we'll figure out how much that matters and report back as well (in the past it's affected performance by as much as 30%). FYI, Schneier reports that SHA-1 is "broken" too: http://www.schneier.com/blog/archives/2005/02/sha1_broken.html (though neither SHA1 nor MD5 collision attacks defeat per se their use within HMACs) Does anyone know of a hash that is alleged to be faster than MD5? Joe --------------enig74F6E9D63269D1A2829A1D5D 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDfQe+E5f5cImnZrsRAjEPAJ9F0nOFrGoYwsdGVVZgs2KtNWgvfQCfTu7d ahajxhcGsMn4kbsgTMFRF4g= =h+4Z -----END PGP SIGNATURE----- --------------enig74F6E9D63269D1A2829A1D5D-- --===============1021011986== 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 --===============1021011986==-- From tcpm-bounces@ietf.org Tue Nov 22 18:50:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eehtz-0001zd-Nu; Tue, 22 Nov 2005 18:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eehtj-0001mI-E0; Tue, 22 Nov 2005 18:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29820; Tue, 22 Nov 2005 18:49:24 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeiCS-0004yp-W6; Tue, 22 Nov 2005 19:09:25 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Eehth-0005a3-LY; Tue, 22 Nov 2005 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 22 Nov 2005 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-dcr-06.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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Improving the Robustness of TCP to Non-Congestion Events Author(s) : S. Bhandarkar, et al. Filename : draft-ietf-tcpm-tcp-dcr-06.txt Pages : 17 Date : 2005-11-22 This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP's loss recovery algorithms treat the receipt of three duplicate acknowledgments as an implicit indication of congestion in the network. This is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-06.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-tcp-dcr-06.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-tcp-dcr-06.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: <2005-11-22165759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-dcr-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-dcr-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-22165759.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 Tue Nov 29 14:41:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBLz-0004V2-4G; Tue, 29 Nov 2005 14:41:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBLy-0004Ux-5b for tcpm@megatron.ietf.org; Tue, 29 Nov 2005 14:41:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25061 for ; Tue, 29 Nov 2005 14:40:41 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhBg5-0000pG-6j for tcpm@ietf.org; Tue, 29 Nov 2005 15:02:14 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jATJeBE29414; Tue, 29 Nov 2005 11:40:11 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jATJeBcC018105; Tue, 29 Nov 2005 11:40:11 -0800 (PST) (envelope-from faber) Date: Tue, 29 Nov 2005 11:40:11 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20051129194010.GG12561@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.1i 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: c0bedb65cce30976f0bf60a0a39edea4 Cc: floyd@icir.org Subject: [tcpm] ECN for SYN/ACK draft 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="===============0805477468==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0805477468== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5uO961YFyoDlzFnP" Content-Disposition: inline --5uO961YFyoDlzFnP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. As those of you who were at tsvwg in Vancouver know, Sally Floyd has proposed a draft adding ECN to SYN and SYN/ACK packets, which was not allowed under the original RFC 3168 ECN spec. The draft has not yet popped out, but there are also relatively-permanent local copies at: http://www.icir.org/floyd/papers/draft-ietf-tsvwg-ecnsyn-00.txt http://www.icir.org/floyd/papers/draft-kuzmanovic-ecn-syn-00.txt The advantage is that a SYN or SYN/ACK packet becomes eligible for marking rather than being dropped and incurring a full RTO during set up. Details are in the draft, of course. This was proposed in tsvwg and was accepted as a WG item there, but eagle-eyed co-chair Mark pointed out that this the draft really addresses a TCP issue and therefore falls under tcpm's umbrella not tsvwg's. When bleary-eyed (closed-eyed?) co-chair Ted was finally roused from his stupor, he agreed. After we hashed it out with the tsvwg co-chairs, the consensus among the various ADs and co-chairs was that the work should go through tcpm. Whichever WG it goes through, the WGLC will happen in both groups. Given that many of the tcpm folks did see the presentation and were among those agreeing to adopt this as a tsvwg work item, I'd like to propose that tcpm adopt it as our work item. N.B. this is a normal request for rough consensus to take the item on, so feedback for adopting it and for not adopting it are both important to see. If accepted, I'd like to request that we move fairly quickly to get this reviewed and on the publication path. I think sending it up to the IESG for Proposed Standard before Dallas would be reasonable, but you all get the final say. If we decide not to accept it, clear reasons need to be given. Comments? Thanks, Ted & Mark --=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 --5uO961YFyoDlzFnP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDjK6aaUz3f+Zf+XsRAhWpAJ0fSN2IxqgiVhvDKD+cdaXeGm2RfACfUfMf xWV4RYmuAumiA9s/2QeqDuY= =wEwN -----END PGP SIGNATURE----- --5uO961YFyoDlzFnP-- --===============0805477468== 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 --===============0805477468==-- From tcpm-bounces@ietf.org Tue Nov 29 15:20:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBxX-00057d-IK; Tue, 29 Nov 2005 15:20:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBxW-00056I-8M for tcpm@megatron.ietf.org; Tue, 29 Nov 2005 15:20:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00255 for ; Tue, 29 Nov 2005 15:19:29 -0500 (EST) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhCHe-0002MZ-4o for tcpm@ietf.org; Tue, 29 Nov 2005 15:41:03 -0500 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id jATKK96c075132; Tue, 29 Nov 2005 12:20:09 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200511292020.jATKK96c075132@cougar.icir.org> To: Ted Faber From: Sally Floyd Date: Tue, 29 Nov 2005 12:20:09 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tcpm@ietf.org Subject: [tcpm] Re: ECN for SYN/ACK draft 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org >As those of you who were at tsvwg in Vancouver know, Sally Floyd has >proposed a draft adding ECN to SYN and SYN/ACK packets, which was not >allowed under the original RFC 3168 ECN spec. The draft, based on a SIGCOMM 2005 paper by Aleksandar Kuzmanovic, proposes allowing the use of ECN for SYN/ACK packets, but *not* for pure SYN packets. The draft is out as: http://www.ietf.org/internet-drafts/draft-kuzmanovic-ecn-syn-00.txt but could transition any day to: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecnsyn-00.txt The only change is in the name. We would really appreciate a few careful reviews, in the hopes that this relatively-simple and straightforward proposal could progress fairly quickly along the path to Proposed Standard. Many thanks, - Sally Abstract: This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specified setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document is specifying the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to an ECN mark by reducing its initial congestion window from two, three, or four segments to one segment, reducing the subsequent load from that connection on the network. Presentation in November at tsvwg: http://www.icir.org/floyd/talks/ECN-SYN-Nov05.pdf http://www.icir.org/floyd/talks/ECN-SYN-Nov05.ppt _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm