From tcpm-bounces@ietf.org Fri Dec 01 14:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqEIJ-0003zg-EF; Fri, 01 Dec 2006 14:43:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqEII-0003zT-Dw; Fri, 01 Dec 2006 14:43:34 -0500 Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqEIF-0004hX-Pv; Fri, 01 Dec 2006 14:43:34 -0500 Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer1.psc.edu (8.13.8/8.13.3) with ESMTP id kB1JhT4O002889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Dec 2006 14:43:29 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id kB1JhTLD002196; Fri, 1 Dec 2006 14:43:29 -0500 Date: Fri, 1 Dec 2006 14:43:29 -0500 (EST) From: Matt Mathis To: TCP Maintenance and Minor Extensions WG In-Reply-To: <10527.201.231.184.157.1164523341.squirrel@www.gont.com.ar> Message-ID: References: <45528D0D.8020800@nttv6.net> <4554D7BA.5020402@isi.edu> <7.0.1.0.0.20061110131546.05a925f8@gont.com.ar> <45575B5D.3050807@isi.edu> <7.0.1.0.0.20061112224002.07dbbbe0@gont.com.ar> <45AB0FAA-2DD1-4C36-A006-6FBC129D06CA@netlab.nec.de> <7.0.1.0.0.20061117232212.089ad4b8@gmx.net> <7.0.1.0.0.20061120000708.04dfde70@gont.com.ar> <45617ECF.3040101@nttv6.net> <7.0.1.0.0.20061122145654.07d24f98@gmx.net> <4566ADEE.8020701@nttv6.net> <7.0.1.0.0.20061124232440.07cab970@gmx.net> <456882CD.5030604@isi.edu> <7.0.1.0.0.20061125100458.02096070@gont.com.ar> <45692D85.4050004@isi.edu> <10527.201.231.184.157.1164523341.squirrel@www.gont.com.ar> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: tsv-dir@ietf.org Subject: [tcpm] Unified ICMP processing: A straw man X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org After several side conversations about the state of ICMP, I decided to try to distill my views down to a fairly crisp argument about how ICMPv4 and ICMPv6 should be uniformly processed by all protocols. There is some evidence that as a community we are already drifting in the direction described below, although not in a very coordinated manner. I would like to test the possibility of finding consensus, loosely based on the following ideas: ICMP should never be mandatory for correct protocol operation. This is now possible because the new path mtu discovery is nearly done. It is desirable to make ICMP work as well as possible because it makes all protocols "friendlier" in the presence of assorted problems. It is risky and undesirable for the default response to any unauthenticated message from the network to be to abort a connection, no matter what the protocol state. Given this, we would like invent appropriate soft error actions for all current hard errors. (And to deprecate the distinction, as has already been done in RFC4443.) If we do this well enough, there is no point in offering the configuration option to abort connections because it just isn't needed. For most protocol states, the right action is to cache ICMP error codes and use them to embellish messages associated with connection timeouts or other events. In some protocol states it is appropriate for ICMP messages to accelerate protocol timers. However we should not assume the details to be self evident. They should be explicit, per protocol. For example it would be appropriate for ICMP unreachable messages reduce TCP's connection timeout from ~2 minutes to a few seconds. However this MUST be configurable. When trying to establish a connection to a node which has multiple addresses (or multiple possible protocols or paths, etc) it is appropriate for ICMP unreachable messages to shorten the headway timer between attempts to successive addresses. I used to think the correct way to do this is to abort earlier connection attempts, but I have recently change my mind: all connection attempts should proceed in concurrently, and the first successful connection should abort all incomplete connections. (I know the common APIs can't implement this, but the standard should describe the preferred behavior). Likewise an "ICMP redirect" could be treated like a routing soft error, and be used to wake some sort of "router discovery" daemon to decide if there is an actionable routing problem. BTW some time ago (10 years?) there was an extensive discussion about tightening the consistency checks for ICMP redirects. (Something to the effect that the from-address for the ICMP should match the actual next hop IP address used by this connection.) Was this ever published as an RFC? Can anybody recall when this conversation happened and which IETF list? All layer 4 protocols have the option to apply protocol specific consistency checks to ICMP messages. The SCTP cookie is probably sufficient authentication justify aborting connections. But this is based on some assumptions about on-path vs off-path attacks. The TCP sequence check may also be applied. Note that in general this is not sufficient authentication to justify aborts. Although I agree with Joe that it is a layer violation in a strict sense, I point out that TCP is loaded with heuristics designed to glean network state from subtle signals. My objection is to prescribing TCP sequence checks as a first line of defense, beyond the true robustness and strength of the technique. It is cheap and easy to implement and helps greatly if there are no other defenses. Other techniques can be applied: e.g. keeping all transmitted headers for some time interval, and matching the entire immutable portion of the header including IP ID, transport checksum etc - expensive but pretty robust against off-path attacks. This can even be applied to encrypted payloads, and may be a desirable techniques in some environments. I would consider modeling all upper layer ICMP consistency checks as optimizations on full header matching. Also note that this really calls into question some of our assumptions about on-path vs off-path attacks. One possible approach would be to make ICMP completely tolerant to on-path attacks by making all ICMP reactions totally "soft": an attacker could cause incorrect error messages, but could not interfere with correct protocol operation, unless the attacker could prevent the delivery of legitimate protocol messages. This approach makes all forms of header matching considerably less valuable. These comments were intended to be protocol independent. Please excuse me if I have messed up some of the details. -------------------------------------------------------------------------- So what next? Here is an updated straw man plan that I suggested to a smaller group: In tcpm: Finish an Informational RFC on TCP sequence checks based on the attacks draft. Must be in the tone "this is how one implementor choose to do it". Must not over represent the strength or value of the defense. Also in tcpm: a quick draft to deprecate responding to source quenches, and possibly tweak some other details. In tsvwg: introduce a problem statement/principles) draft, to cover the following topics: - State some goals: review and unify ICMP processing across all protocols rationalize how ICMP fits into 7 layers (?) - Inventory the problem Observe that most ICMP specifications are adjunct to other protocols There are ~490 RFCs (and 200+ IDs) that reference ICMP Need some analysis and a plan here - Possible philosophical direction (Follow the general points above): All ICMP should be advisory Loosing ICMP should never be fatal ICMP messages should be cached for upper layers to consult as needed In some cases ICMP accelerates protocol timers Add per protocol validity checking where it makes sense ICMP should fit into (or prototype) a good interlayer message model for general event notification(?) A follow on "Unified ICMP" document would replace the relevant sections in RFC1122, "host requirements", (section 3.2.2 "ICMP" and 4.2.3.9, "TCP response to ICMP messages") and perhaps (sections of) other key documents. This would probably be in tsvwg, with input from tcpm. It may need to be be more than one document. Draft a "ICMP Updates" document that would amend or validate all standards track documents that mention ICMP, to bring everything into conformance with the new Unified ICMP spec. --------------------------------------------------------------------------- This is a huge among of work, and is not going to converge unless we can get at least some initial consensus on the key technical points. At this stage I am mostly interested to know if there are substantial disagreements with my technical observations. If there is basic technical agreement the plan will work itself out. What do people think? Have I missed anything major? Am I way off base on anything? Are my ICMP principles sound? Thanks --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Dec 03 08:44:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqrcu-0005Xi-7V; Sun, 03 Dec 2006 08:43:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqrcs-0005X0-Lh; Sun, 03 Dec 2006 08:43:26 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqrcV-000412-0M; Sun, 03 Dec 2006 08:43:04 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id kB3Dh2DZ009176; Sun, 3 Dec 2006 08:43:02 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kB3Dh2ir220316; Sun, 3 Dec 2006 08:43:02 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kB3Dh2U0028491; Sun, 3 Dec 2006 08:43:02 -0500 Received: from cichlid.raleigh.ibm.com (wecm-9-67-116-173.wecm.ibm.com [9.67.116.173]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kB3Dh1NM028470; Sun, 3 Dec 2006 08:43:01 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id kB3DgNt5026866; Sun, 3 Dec 2006 08:42:26 -0500 Message-Id: <200612031342.kB3DgNt5026866@cichlid.raleigh.ibm.com> To: Matt Mathis Subject: Re: [tcpm] Unified ICMP processing: A straw man In-reply-to: References: <45528D0D.8020800@nttv6.net> <4554D7BA.5020402@isi.edu> <7.0.1.0.0.20061110131546.05a925f8@gont.com.ar> <45575B5D.3050807@isi.edu> <7.0.1.0.0.20061112224002.07dbbbe0@gont.com.ar> <45AB0FAA-2DD1-4C36-A006-6FBC129D06CA@netlab.nec.de> <7.0.1.0.0.20061117232212.089ad4b8@gmx.net> <7.0.1.0.0.20061120000708.04dfde70@gont.com.ar> <45617ECF.3040101@nttv6.net> <7.0.1.0.0.20061122145654.07d24f98@gmx.net> <4566ADEE.8020701@nttv6.net> <7.0.1.0.0.20061124232440.07cab970@gmx.net> <456882CD.5030604@isi.edu> <7.0.1.0.0.20061125100458.02096070@gont.com.ar> <45692D85.4050004@isi.edu> <10527.201.231.184.157.1164523341.squirrel@www.gont.com.ar> Comments: In-reply-to Matt Mathis message dated "Fri, 01 Dec 2006 14:43:29 -0500." Date: Sun, 03 Dec 2006 08:42:23 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: TCP Maintenance and Minor Extensions WG , tsv-dir@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi Matt. Thanks for this note. I think this is an interesting and probably inevitable way we should evolve with ICMPs. And I'm generally in favor of trying to unify and pull together the overall thinking of where we are at with ICMP. On one specific point... Matt Mathis writes: > Likewise an "ICMP redirect" could be treated like a routing soft > error, and be used to wake some sort of "router discovery" daemon to > decide if there is an actionable routing problem. BTW some time ago > (10 years?) there was an extensive discussion about tightening the > consistency checks for ICMP redirects. (Something to the effect > that the from-address for the ICMP should match the actual next hop > IP address used by this connection.) Was this ever published as an > RFC? Can anybody recall when this conversation happened and which > IETF list? FYI, IPv6 does this. From RFC 2461: > 8.1. Validation of Redirect Messages > > A host MUST silently discard any received Redirect message that does > not satisfy all of the following validity checks: ... > - The IP source address of the Redirect is the same as the current > first-hop router for the specified ICMP Destination Address. Thomas _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Dec 03 12:25:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqv5B-0004Zx-Rj; Sun, 03 Dec 2006 12:24:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqv59-0004Zp-RE; Sun, 03 Dec 2006 12:24:51 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gqv56-000665-Rw; Sun, 03 Dec 2006 12:24:51 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 6EB97F0C420; Sun, 3 Dec 2006 14:24:40 -0300 (ART) Received: from fgont.gont.com.ar (157-184-231-201.fibertel.com.ar [201.231.184.157]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id kB3HOVeW013235; Sun, 3 Dec 2006 14:24:33 -0300 Message-Id: <7.0.1.0.0.20061203131622.07ff52e8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 03 Dec 2006 14:23:45 -0300 To: Matt Mathis , TCP Maintenance and Minor Extensions WG From: Fernando Gont Subject: Re: [tcpm] Unified ICMP processing: A straw man In-Reply-To: References: <45528D0D.8020800@nttv6.net> <4554D7BA.5020402@isi.edu> <7.0.1.0.0.20061110131546.05a925f8@gont.com.ar> <45575B5D.3050807@isi.edu> <7.0.1.0.0.20061112224002.07dbbbe0@gont.com.ar> <45AB0FAA-2DD1-4C36-A006-6FBC129D06CA@netlab.nec.de> <7.0.1.0.0.20061117232212.089ad4b8@gmx.net> <7.0.1.0.0.20061120000708.04dfde70@gont.com.ar> <45617ECF.3040101@nttv6.net> <7.0.1.0.0.20061122145654.07d24f98@gmx.net> <4566ADEE.8020701@nttv6.net> <7.0.1.0.0.20061124232440.07cab970@gmx.net> <456882CD.5030604@isi.edu> <7.0.1.0.0.20061125100458.02096070@gont.com.ar> <45692D85.4050004@isi.edu> <10527.201.231.184.157.1164523341.squirrel@www.gont.com.ar> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Sun, 03 Dec 2006 14:24:39 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: tsv-dir@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Matt, I agree with most of the technical comments in your e-mail. Regarding the plan, my view is the following: There's currently two drafts in the tcpm wg that are aiming at Informational. One describes the problem of long delays between connection-establishment attempts (draft-ietf-tcp-soft-errors) and the other one describes the issue of ICMP attacks against TCP. These two docs are meant to describe what the industry has done on the subject (and, FWIW, have received lots of feedback from open source OSes). My view is that these two docs should be moved forward (on the Informational path). They document what the industry has done, and have been of help to quite a bunch of documents (referenced in a few RFCs, about ten IDs (including one by the IAB), and a few papers on the subject). FWIW, I believe the soft errors draft is ready for WGLC (there's a revision to be posted soon)... The ICMP attacks draft needs to be tweaked, as it is still too prescriptive, but that's what the focus of the next revision would be on. At the same time, I think we should be doing the plan you suggest. When making actual changes to the standard, both of the icmp docs (icmp attacks and tcp soft errors) will probably be good Informative references. I wouldn't object, though, to pull the TCP SEQ and the ICMP SQ stuff, and make them the two drafts you mentioned in your plan, while keeping a brief discussion about the tcp seq and ICMP SQ in the icmp attacks draft. (BTW, you mention that they should be "Informational"... however, I'd probably aim at std track). No need to say, I volunteer to work on the docs you proposed in your plan, and help to push the "Unified ICMP" idea move forward. Kindest regards, Fernando Gont >After several side conversations about the state of ICMP, I decided to try to >distill my views down to a fairly crisp argument about how ICMPv4 and ICMPv6 >should be uniformly processed by all protocols. There is some evidence that >as a community we are already drifting in the direction described below, >although not in a very coordinated manner. I would like to test the >possibility of finding consensus, loosely based on the following ideas: > >ICMP should never be mandatory for correct protocol operation. This is now >possible because the new path mtu discovery is nearly done. It is desirable >to make ICMP work as well as possible because it makes all protocols >"friendlier" in the presence of assorted problems. > >It is risky and undesirable for the default response to any unauthenticated >message from the network to be to abort a connection, no matter what the >protocol state. Given this, we would like invent appropriate soft error >actions for all current hard errors. (And to deprecate the distinction, as >has already been done in RFC4443.) > >If we do this well enough, there is no point in offering the configuration >option to abort connections because it just isn't needed. > >For most protocol states, the right action is to cache ICMP error codes and >use them to embellish messages associated with connection timeouts or other >events. > >In some protocol states it is appropriate for ICMP messages to accelerate >protocol timers. However we should not assume the details to be self >evident. They should be explicit, per protocol. > >For example it would be appropriate for ICMP unreachable messages reduce TCP's >connection timeout from ~2 minutes to a few seconds. However this MUST be >configurable. > >When trying to establish a connection to a node which has multiple addresses >(or multiple possible protocols or paths, etc) it is appropriate for ICMP >unreachable messages to shorten the headway timer between attempts to >successive addresses. I used to think the correct way to do this is to abort >earlier connection attempts, but I have recently change my mind: all >connection attempts should proceed in concurrently, and the first successful >connection should abort all incomplete connections. (I know the common APIs >can't implement this, but the standard should describe the preferred >behavior). > >Likewise an "ICMP redirect" could be treated like a routing soft error, and be >used to wake some sort of "router discovery" daemon to decide if there is an >actionable routing problem. BTW some time ago (10 years?) there was an >extensive discussion about tightening the consistency checks for ICMP >redirects. (Something to the effect that the from-address for the ICMP should >match the actual next hop IP address used by this connection.) Was this ever >published as an RFC? Can anybody recall when this conversation happened and >which IETF list? > >All layer 4 protocols have the option to apply protocol specific consistency >checks to ICMP messages. The SCTP cookie is probably sufficient >authentication justify aborting connections. But this is based on some >assumptions about on-path vs off-path attacks. > >The TCP sequence check may also be applied. Note that in general this is not >sufficient authentication to justify aborts. Although I agree with Joe >that it is a layer violation in a strict sense, I point out that TCP is >loaded with heuristics designed to glean network state from subtle signals. >My objection is to prescribing TCP sequence checks as a first line of defense, >beyond the true robustness and strength of the technique. It is cheap and >easy to implement and helps greatly if there are no other defenses. > >Other techniques can be applied: e.g. keeping all transmitted headers for some >time interval, and matching the entire immutable portion of the header >including IP ID, transport checksum etc - expensive but pretty robust against >off-path attacks. This can even be applied to encrypted payloads, and may be >a desirable techniques in some environments. I would consider modeling all >upper layer ICMP consistency checks as optimizations on full header matching. > >Also note that this really calls into question some of our assumptions about >on-path vs off-path attacks. One possible approach would be to make ICMP >completely tolerant to on-path attacks by making all ICMP reactions totally >"soft": an attacker could cause incorrect error messages, but could not >interfere with correct protocol operation, unless the attacker could prevent >the delivery of legitimate protocol messages. This approach makes all >forms of header matching considerably less valuable. > >These comments were intended to be protocol independent. Please excuse me if >I have messed up some of the details. > >-------------------------------------------------------------------------- >So what next? > >Here is an updated straw man plan that I suggested to a smaller group: > >In tcpm: Finish an Informational RFC on TCP sequence checks based on the >attacks draft. Must be in the tone "this is how one implementor choose to do >it". Must not over represent the strength or value of the defense. > >Also in tcpm: a quick draft to deprecate responding to source quenches, and >possibly tweak some other details. > >In tsvwg: introduce a problem statement/principles) draft, to cover the >following topics: > - State some goals: > review and unify ICMP processing across all protocols > rationalize how ICMP fits into 7 layers (?) > - Inventory the problem > Observe that most ICMP specifications are adjunct to other protocols > There are ~490 RFCs (and 200+ IDs) that reference ICMP > Need some analysis and a plan here > - Possible philosophical direction (Follow the general points above): > All ICMP should be advisory > Loosing ICMP should never be fatal > ICMP messages should be cached for upper layers to consult as needed > In some cases ICMP accelerates protocol timers > Add per protocol validity checking where it makes sense > ICMP should fit into (or prototype) a good interlayer message > model for general event notification(?) > >A follow on "Unified ICMP" document would replace the relevant sections in >RFC1122, "host requirements", (section 3.2.2 "ICMP" and 4.2.3.9, >"TCP response to ICMP >messages") and perhaps (sections of) other key documents. This would probably >be in tsvwg, with input from tcpm. It may need to be be more than one >document. > >Draft a "ICMP Updates" document that would amend or validate all standards >track documents that mention ICMP, to bring everything into conformance with >the new Unified ICMP spec. > >--------------------------------------------------------------------------- > >This is a huge among of work, and is not going to converge unless we can get >at least some initial consensus on the key technical points. > >At this stage I am mostly interested to know if there are substantial >disagreements with my technical observations. If there is basic technical >agreement the plan will work itself out. > >What do people think? Have I missed anything major? Am I way off base on >anything? Are my ICMP principles sound? > >Thanks >--MM-- >------------------------------------------- >Matt Mathis http://www.psc.edu/~mathis >Work:412.268.3319 Home/Cell:412.654.7529 >------------------------------------------- >Evil is defined by mortals who think they know >"The Truth" and use force to apply it to others. > > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Dec 05 20:07:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrlEc-00024X-2y; Tue, 05 Dec 2006 20:06:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrlEa-00024N-MT; Tue, 05 Dec 2006 20:06:04 -0500 Received: from mailer2.psc.edu ([128.182.66.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrlEY-0004wZ-Ek; Tue, 05 Dec 2006 20:06:04 -0500 Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer2.psc.edu (8.13.8/8.13.3) with ESMTP id kB616144004863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Dec 2006 20:06:01 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id kB61608f006843; Tue, 5 Dec 2006 20:06:01 -0500 Date: Tue, 5 Dec 2006 20:06:00 -0500 (EST) From: Matt Mathis To: TCP Maintenance and Minor Extensions WG In-Reply-To: Message-ID: References: <45528D0D.8020800@nttv6.net> <4554D7BA.5020402@isi.edu> <7.0.1.0.0.20061110131546.05a925f8@gont.com.ar> <45575B5D.3050807@isi.edu> <7.0.1.0.0.20061112224002.07dbbbe0@gont.com.ar> <45AB0FAA-2DD1-4C36-A006-6FBC129D06CA@netlab.nec.de> <7.0.1.0.0.20061117232212.089ad4b8@gmx.net> <7.0.1.0.0.20061120000708.04dfde70@gont.com.ar> <45617ECF.3040101@nttv6.net> <7.0.1.0.0.20061122145654.07d24f98@gmx.net> <4566ADEE.8020701@nttv6.net> <7.0.1.0.0.20061124232440.07cab970@gmx.net> <456882CD.5030604@isi.edu> <7.0.1.0.0.20061125100458.02096070@gont.com.ar> <45692D85.4050004@isi.edu> <10527.201.231.184.157.1164523341.squirrel@www.gont.com.ar> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: tsv-dir@ietf.org Subject: [tcpm] TAKE TWO: Unified ICMP processing: A straw man X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I have recived zero negative responses and just a few positive responses to my "straw man" message. I would like to amend my request: If you think my technical points are correct and would like to see this pursued in tcmp and tsvwg, please speak up. (But go easy on the list). Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Dec 06 17:58:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5hP-0005E5-ST; Wed, 06 Dec 2006 17:57:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5hM-0005Ds-UD; Wed, 06 Dec 2006 17:57:08 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs5h4-0000YC-2X; Wed, 06 Dec 2006 17:57:08 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kB6MuWwu022984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Dec 2006 14:56:33 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id kB6MuWTZ029395; Wed, 6 Dec 2006 14:56:32 -0800 (PST) (envelope-from faber) Date: Wed, 6 Dec 2006 14:56:32 -0800 From: Ted Faber To: Matt Mathis Subject: Re: [tcpm] TAKE TWO: Unified ICMP processing: A straw man Message-ID: <20061206225632.GL22046@hut.isi.edu> References: <45617ECF.3040101@nttv6.net> <7.0.1.0.0.20061122145654.07d24f98@gmx.net> <4566ADEE.8020701@nttv6.net> <7.0.1.0.0.20061124232440.07cab970@gmx.net> <456882CD.5030604@isi.edu> <7.0.1.0.0.20061125100458.02096070@gont.com.ar> <45692D85.4050004@isi.edu> <10527.201.231.184.157.1164523341.squirrel@www.gont.com.ar> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.2i 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 Cc: TCP Maintenance and Minor Extensions WG , tsv-dir@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="===============0379503617==" Errors-To: tcpm-bounces@ietf.org --===============0379503617== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pFej7zHSL6C5fFIz" Content-Disposition: inline --pFej7zHSL6C5fFIz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 05, 2006 at 08:06:00PM -0500, Matt Mathis wrote: > I have recived zero negative responses and just a few positive responses = to > my "straw man" message. I would like to amend my request: >=20 > If you think my technical points are correct and would like to see this > pursued in tcmp and tsvwg, please speak up. (But go easy on the list). I think these things. --=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 --pFej7zHSL6C5fFIz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFd0qgaUz3f+Zf+XsRAsHxAKDeCh6Gi5zc1xJN9Gayu+s4g6zr+wCfahOt IzxCKMjJALH4YoPgVsr3Lnk= =xaWq -----END PGP SIGNATURE----- --pFej7zHSL6C5fFIz-- --===============0379503617== 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 --===============0379503617==-- From tcpm-bounces@ietf.org Wed Dec 06 18:04:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5og-0000X9-JC; Wed, 06 Dec 2006 18:04:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5of-0000X0-5p; Wed, 06 Dec 2006 18:04:41 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs5oc-0001qb-TH; Wed, 06 Dec 2006 18:04:41 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kB6N4XIP007829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2006 17:04:38 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kB6N4Xkm028167; Wed, 6 Dec 2006 17:04:33 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kB6N4KME027649; Wed, 6 Dec 2006 17:04:33 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 15:04:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] TAKE TWO: Unified ICMP processing: A straw man Date: Wed, 6 Dec 2006 15:04:26 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774512@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TAKE TWO: Unified ICMP processing: A straw man Thread-Index: AccY0wBsnvtCDk5uRauVwt6skb+QcwAt7E6A From: "Templin, Fred L" To: "Matt Mathis" , "TCP Maintenance and Minor Extensions WG" X-OriginalArrivalTime: 06 Dec 2006 23:04:27.0748 (UTC) FILETIME=[E12EF240:01C7198A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tsv-dir@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I think your techical points are correct, but I have no opinion on the forum where they should be pursued.=20 -----Original Message----- From: Matt Mathis [mailto:mathis@psc.edu]=20 Sent: Tuesday, December 05, 2006 5:06 PM To: TCP Maintenance and Minor Extensions WG Cc: tsv-dir@ietf.org Subject: [tcpm] TAKE TWO: Unified ICMP processing: A straw man I have recived zero negative responses and just a few positive responses to my "straw man" message. I would like to amend my request: If you think my technical points are correct and would like to see this pursued in tcmp and tsvwg, please speak up. (But go easy on the list). Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Dec 06 18:28:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6BG-00033U-4j; Wed, 06 Dec 2006 18:28:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6BF-00033L-2y; Wed, 06 Dec 2006 18:28:01 -0500 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs6BC-0005jN-JN; Wed, 06 Dec 2006 18:28:01 -0500 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id kB6NRp8b026729; Wed, 6 Dec 2006 15:27:51 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 15:27:51 -0800 Received: from [192.168.117.73] ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 15:27:51 -0800 In-Reply-To: References: <45528D0D.8020800@nttv6.net> <4554D7BA.5020402@isi.edu> <7.0.1.0.0.20061110131546.05a925f8@gont.com.ar> <45575B5D.3050807@isi.edu> <7.0.1.0.0.20061112224002.07dbbbe0@gont.com.ar> <45AB0FAA-2DD1-4C36-A006-6FBC129D06CA@netlab.nec.de> <7.0.1.0.0.20061117232212.089ad4b8@gmx.net> <7.0.1.0.0.20061120000708.04dfde70@gont.com.ar> <45617ECF.3040101@nttv6.net> <7.0.1.0.0.20061122145654.07d24f98@gmx.net> <4566ADEE.8020701@nttv6.net> <7.0.1.0.0.20061124232440.07cab970@gmx.net> <456882CD.5030604@isi.edu> <7.0.1.0.0.20061125100458.02096070@gont.com.ar> <45692D85.4050004@isi.edu> <10527.201.231.184.157.1164523341.squirrel@www.gont.com.ar> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <557C971B-3C98-4949-ABB0-6D20E3353DFA@windriver.com> Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] TAKE TWO: Unified ICMP processing: A straw man Date: Wed, 6 Dec 2006 17:28:37 -0600 To: Matt Mathis X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 06 Dec 2006 23:27:51.0235 (UTC) FILETIME=[25BA1130:01C7198E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: TCP Maintenance and Minor Extensions WG , tsv-dir@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Yes, I think this should be pursued. Probably this should be in tsvwg, not tcpm, even if TCP is the motivation for doing the work. I also view this in at least two distinct parts that are somewhat orthogonal to each other. First, when an ICMP packet arrives, do I believe that it is a legitimate ICMP packet? How do I go about checking the packet? How should hosts/routers generate ICMP messages? (Mostly a question of how much of the original packet do you return). What sort of checks are generic at the IP/ICMP layer? What additional checks/ verifications do the upper level protocols use when the ICMP message is delivered to them? The second category is now that I have an ICMP packet and I've decided that it is legitimate (to some degree), how seriously do I take it? Is it a hard error, or just a suggestion of something that might be wrong? Do I drop connections based on this? Believing that an ICMP packet is legitimate is probably not a yes/no answer, it will probably have shades of gray. If so, that would then become part of the input to the second category. I think it'll be a lot easier to get something written if issues are categorized into one of these two areas, and we avoid mingling them as much as possible in the document. -David On Dec 5, 2006, at 7:06 PM, Matt Mathis wrote: > I have recived zero negative responses and just a few positive > responses to > my "straw man" message. I would like to amend my request: > > If you think my technical points are correct and would like to see > this > pursued in tcmp and tsvwg, please speak up. (But go easy on the > list). > > Thanks, > --MM-- > ------------------------------------------- > Matt Mathis http://www.psc.edu/~mathis > Work:412.268.3319 Home/Cell:412.654.7529 > ------------------------------------------- > Evil is defined by mortals who think they know > "The Truth" and use force to apply it to others. > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Dec 06 22:48:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsAF1-0002Az-9b; Wed, 06 Dec 2006 22:48:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsAF0-0002Ah-1g; Wed, 06 Dec 2006 22:48:10 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsAEy-0008Ch-MT; Wed, 06 Dec 2006 22:48:10 -0500 Received: from [127.0.0.1] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kB73llLX002351; Wed, 6 Dec 2006 19:47:48 -0800 (PST) Message-ID: <45778EE0.5060604@isi.edu> Date: Wed, 06 Dec 2006 19:47:44 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Matt Mathis Subject: Re: [tcpm] TAKE TWO: Unified ICMP processing: A straw man References: <45528D0D.8020800@nttv6.net> <4554D7BA.5020402@isi.edu> <7.0.1.0.0.20061110131546.05a925f8@gont.com.ar> <45575B5D.3050807@isi.edu> <7.0.1.0.0.20061112224002.07dbbbe0@gont.com.ar> <45AB0FAA-2DD1-4C36-A006-6FBC129D06CA@netlab.nec.de> <7.0.1.0.0.20061117232212.089ad4b8@gmx.net> <7.0.1.0.0.20061120000708.04dfde70@gont.com.ar> <45617ECF.3040101@nttv6.net> <7.0.1.0.0.20061122145654.07d24f98@gmx.net> <4566ADEE.8020701@nttv6.net> <7.0.1.0.0.20061124232440.07cab970@gmx.net> <456882CD.5030604@isi.edu> <7.0.1.0.0.20061125100458.02096070@gont.com.ar> <45692D85.4050004@isi.edu> <10527.201.231.184.157.1164523341.squirrel@www.gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.94.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: 4d87d2aa806f79fed918a62e834505ca Cc: TCP Maintenance and Minor Extensions WG , tsv-dir@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="===============1697711473==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1697711473== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5EBB18D88174C39262EA5A27" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5EBB18D88174C39262EA5A27 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Matt Mathis wrote: > I have recived zero negative responses and just a few positive response= s to > my "straw man" message. I would like to amend my request: >=20 > If you think my technical points are correct and would like to see this= > pursued in tcmp and tsvwg, please speak up. (But go easy=20 I think some of the points are correct, but others have far-reaching ramifications. If all ICMPs are advisory, e.g., then some things we rely on for correct operation would silently fail (redirects, in particular). Also in particular, sequence checks on ICMPs to transport protocols may make sense, BUT the question is "what is the window". Unack'd data is not appropriate; meaningful messages can take longer than that to be received, since ICMP is a slow-path mechanism. The real question is whether there is a meaningful window - other than 'anywhere' - that can be specified. Overall, I'm not sure an absolute approach is feasible. If pursued, given the ramifications to so many protocols (transport, network, and routing), this is beyond TSVWG, but might be appropriate for IntArea to create a WG for. Joe --------------enig5EBB18D88174C39262EA5A27 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFd47gE5f5cImnZrsRAmutAKCwSBRkh8KhKcJnMJQrUu3CRZVrhgCgpBsl USK8/c52n2a+gRK6PzAxAxw= =Tt/V -----END PGP SIGNATURE----- --------------enig5EBB18D88174C39262EA5A27-- --===============1697711473== 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 --===============1697711473==-- From tcpm-bounces@ietf.org Wed Dec 06 23:11:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsAb2-0005cR-0h; Wed, 06 Dec 2006 23:10:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsAb1-0005c6-DM; Wed, 06 Dec 2006 23:10:55 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsAb0-0004G6-1u; Wed, 06 Dec 2006 23:10:55 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id kB74Aqpt027289; Wed, 6 Dec 2006 20:10:53 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 0189256245A; Wed, 6 Dec 2006 23:10:49 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 10EBB14ACFE; Wed, 6 Dec 2006 23:10:34 -0500 (EST) To: Matt Mathis From: Mark Allman In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: They're Coming to Take Me Away MIME-Version: 1.0 Date: Wed, 06 Dec 2006 23:10:33 -0500 Message-Id: <20061207041034.10EBB14ACFE@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: TCP Maintenance and Minor Extensions WG , tsv-dir@ietf.org Subject: [tcpm] Re: [tsv-dir] TAKE TWO: Unified ICMP processing: A straw man 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="===============1772971289==" Errors-To: tcpm-bounces@ietf.org --===============1772971289== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline [TCPM WG co-chair hat OFF.] > I have recived zero negative responses and just a few positive > responses to my "straw man" message. I would like to amend my > request: > > If you think my technical points are correct and would like to see > this pursued in tcmp and tsvwg, please speak up. (But go easy on the > list). I like your straw man and generally support it (meaning, I might quibble here and there, but think that it is significantly the right path). allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFd5Q5WyrrWs4yIs4RAn23AKCG4KNlGmOvrnN668xSRIqTjsfHbwCfb6AR Y83fZTiVx/+MnKxvD5A2Szk= =5R22 -----END PGP SIGNATURE----- --=_bOundary-- --===============1772971289== 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 --===============1772971289==-- From tcpm-bounces@ietf.org Wed Dec 06 23:31:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsAud-000841-RO; Wed, 06 Dec 2006 23:31:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsAuc-00083i-VN; Wed, 06 Dec 2006 23:31:10 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsAub-0006U6-JD; Wed, 06 Dec 2006 23:31:10 -0500 Received: from [127.0.0.1] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kB74Uuif012403; Wed, 6 Dec 2006 20:30:56 -0800 (PST) Message-ID: <457798FD.3030807@isi.edu> Date: Wed, 06 Dec 2006 20:30:53 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] Re: [tsv-dir] TAKE TWO: Unified ICMP processing: A straw man References: <20061207041038.4131214AD10@lawyers.icir.org> In-Reply-To: <20061207041038.4131214AD10@lawyers.icir.org> X-Enigmail-Version: 0.94.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 Cc: TCP Maintenance and Minor Extensions WG , tsv-dir@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="===============0240501139==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0240501139== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig912AB05FFBDFF69A67858D7E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig912AB05FFBDFF69A67858D7E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Allman wrote: > [TCPM WG co-chair hat ON.] =2E.. > Currently, the TCPM WG has decided to take on two work items in this > space. The soft errors document is intended to be an informational > accounting of how TCP stacks currently handle ICMPs in terms of changin= g > the so-called 'hard errors' into 'soft errors'. The ICMP attacks > document is informational and is focused on what TCP stacks do to > validate incoming ICMPs. =2E.. > Further, I read Matt's proposal as saying we should forget these > documents. At least the attack document since he calls out two of the > items from that document as possible quick stand-alone documents > (depricating SQ and sequence number checking). Maybe this is a > mis-read. But, correcting that would be answering the real question...= =20 Deprecating SQ is fine. Seq num checking needs a real determination of what a valid range _should_ be, not just picking one that TCP happens to have at its disposa= l. Joe --------------enig912AB05FFBDFF69A67858D7E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFd5j9E5f5cImnZrsRAr+lAJ0WjSyB4KlOYX/NSa3qM8l4jcD1mwCdFccT o/QZn2GXR+/M9kcAHBPwMZU= =74Qy -----END PGP SIGNATURE----- --------------enig912AB05FFBDFF69A67858D7E-- --===============0240501139== 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 --===============0240501139==-- From tcpm-bounces@ietf.org Thu Dec 07 10:02:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKlD-0006NG-Dg; Thu, 07 Dec 2006 10:02:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKlC-0006N5-6n; Thu, 07 Dec 2006 10:02:06 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsKl7-0005At-GL; Thu, 07 Dec 2006 10:02:04 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 60666F0C582; Thu, 7 Dec 2006 12:01:53 -0300 (ART) Received: from fgont.gont.com.ar (157-184-231-201.fibertel.com.ar [201.231.184.157]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id kB7F0kC4003910; Thu, 7 Dec 2006 12:01:10 -0300 Message-Id: <7.0.1.0.0.20061207102856.0671d6d0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 07 Dec 2006 11:17:36 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Thu, 07 Dec 2006 12:01:46 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: tsv-dir@ietf.org Subject: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and TCP's reaction to soft errors) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, I would like to state my opinion on the question asked by Mark (wrt what we would do with the ICMP docs if we were to take Matts suggestion for working on ICMP): * Both of the drafts are aiming at Informational, thus just describing "what is implemented out there". No matter what we end up standardizing, that will not change what is currently implemented out there. That's one of the reasons for which I think that even if we got consensus to proceed as suggested by Matt, both documents should still be moved forward on the Informational path. * In the case of the ICMP attacks draft, one of the goals of the document is to discuss ICMP-based attacks (other than "proposing mitigations). And many have argued that it is really needed (e.g., it is not clear to everybody how TCP MD5, IPsec, etc, interact with ICMP and TCP... and that's one of the things the draft tries to clarify). * There are already a few RFCs, around ten internet drafts (including one by the IAB), and a few papers referencing it, and it is worth noting that while we have two documents on TCP-based spoofing attacks (antispoof and tcpsecure), if we were to drop the ICMP attacks draft we would end up having no doc describing ICMP attacks against TCP (which, ironically, are simpler than their TCP-based counter-part). * Another thing with the ICMP attacks draft is that it describes quite a few mitigations that have been widely implemented, and not just the TCP SEQ check and that of dropping ICMP SQ. Therefore, even if we were to pull the ICMP SQ and the TCP SEQ check stuff from the document, there's still more stuff in the document that makes the draft worth publishing. * I agree that the ICMP attacks draft needs more work. In the last few revisions I have been addressing lots of technical comments posted by many of you on the list. That's why I have not yet completely tackled those parts of the draft that are still "too prescriptive". This is going to be the goal of the next revision which, in the event anybody sends text (it's a wg doc!), will probably converge even sooner than expected. * In the case of the ICMP soft errors draft, we have had discussions for the last two years, and we didn't get consensus to standardize the "abort the connection reset upon receipt of an ICMP soft error". But there are many implementations that already perform some alternative reaction to ICMP error messages received during the connection-establishment phase. I think we had already got consensus to document it. And the draft is very close (if not already) for WGLC (we bounced the doc a few times with Mark, and I will be able to publish a revision anytime soon). * It is worth noting that we were recently talking about how to encourage participation of open source projects in the IETF. The ICMP attacks draft has benefited from the feedback of all major open source OSes, along the two years it has been around. While we certainly should not make a decision based exclusively on this point, I'm not sure all those guys would be happy to provide feedback on future drafts if they realize that the time they spent during two years contributing to an IETF doc basically ended up in nothing. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Dec 07 10:31:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLDW-0000bE-QB; Thu, 07 Dec 2006 10:31:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLDU-0000aL-NI; Thu, 07 Dec 2006 10:31:20 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsLDN-0005w7-9N; Thu, 07 Dec 2006 10:31:20 -0500 Received: from [127.0.0.1] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kB7FUfh5022201; Thu, 7 Dec 2006 07:30:42 -0800 (PST) Message-ID: <4578339E.9040806@isi.edu> Date: Thu, 07 Dec 2006 07:30:38 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and TCP's reaction to soft errors) References: <7.0.1.0.0.20061207102856.0671d6d0@gont.com.ar> In-Reply-To: <7.0.1.0.0.20061207102856.0671d6d0@gont.com.ar> X-Enigmail-Version: 0.94.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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tcpm@ietf.org, tsv-dir@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="===============1027503095==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1027503095== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF74B9323AA1AAD7DE5D76E8F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF74B9323AA1AAD7DE5D76E8F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: =2E... > * It is worth noting that we were recently talking about how to > encourage participation of open source projects in the IETF. The ICMP > attacks draft has benefited from the feedback of all major open source > OSes, along the two years it has been around. While we certainly should= > not make a decision based exclusively on this point, I'm not sure all > those guys would be happy to provide feedback on future drafts if they > realize that the time they spent during two years contributing to an > IETF doc basically ended up in nothing. Perhaps knowing that "deploy widely first, document and validate later" is not how the IETF works is appropriate feedback for that community, esp. overzealous segments of it. Joe --------------enigF74B9323AA1AAD7DE5D76E8F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFeDOeE5f5cImnZrsRAqdgAJ44Ch+G/PaKOd4T7+c96ysmTTjWXQCfZCJE eyXW4e0Y+szwMJt8yJFBOVM= =nf5F -----END PGP SIGNATURE----- --------------enigF74B9323AA1AAD7DE5D76E8F-- --===============1027503095== 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 --===============1027503095==-- From tcpm-bounces@ietf.org Thu Dec 07 10:31:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLDW-0000ak-JY; Thu, 07 Dec 2006 10:31:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLDU-0000aG-Nn for tcpm@ietf.org; Thu, 07 Dec 2006 10:31:20 -0500 Received: from whisker.bluecoat.com ([216.52.23.28]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsLDA-0001G0-Sr for tcpm@ietf.org; Thu, 07 Dec 2006 10:31:20 -0500 Received: from bcs-mail2.internal.cacheflow.com (bcs-mail2.internal.cacheflow.com [10.2.2.59]) by whisker.bluecoat.com (8.13.8/8.13.8) with ESMTP id kB7FUxQP026456 for ; Thu, 7 Dec 2006 07:30:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C71A14.AEF79451" Date: Thu, 7 Dec 2006 07:29:12 -0800 Message-ID: <305C539CA2F86249BF51CDCE8996AFF41CD794@bcs-mail2.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: <305C539CA2F86249BF51CDCE8996AFF41CD794@bcs-mail2.internal.cacheflow.com> Thread-Topic: TAKE TWO: Unified ICMP processing: A straw man Thread-Index: AccaEK3dqc3TfHxVRZS6nXT1/ybHhwAA8ROf References: From: "Mahdavi, Jamshid" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [tcpm] RE: TAKE TWO: Unified ICMP processing: A straw man X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C71A14.AEF79451 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joe Touch wrote: > I think some of the points are correct, but others have far-reaching > ramifications. If all ICMPs are advisory, e.g., then some things we = rely > on for correct operation would silently fail (redirects, in = particular). I think that ICMP redirects are absolutely advisory. We have lots of=20 cases where people ignore redirects, disable sending them, or = periodically clear the list of redirect learned routes. I'm not sure what could be more advisory than that. --J ------_=_NextPart_001_01C71A14.AEF79451 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjcPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAMwAAAFJFOiBUQUtFIFRXTzogVW5p ZmllZCBJQ01QIHByb2Nlc3Npbmc6IEEgc3RyYXcgbWFuADwQAQWAAwAOAAAA1gcMAAcABwAdAAwA BAAkAQEggAMADgAAANYHDAAHAAcAHgA2AAQATwEBCYABACEAAAA1NUE5MkQwRkZGNzEwMzQwQjhC REE1MTZDODE2MTg5RgAyBwEDkAYAiAkAADkAAAADACYAAAAAAAMANgAAAAAAQAA5ANG2K3IUGscB HgA9AAEAAAAFAAAAUkU6IAAAAAACAUcAAQAAADYAAABjPVVTO2E9IDtwPUNBQ0hFRkxPVztsPUJD Uy1NQUlMMi0wNjEyMDcxNTMwNTRaLTE3ODQ3MQAAAB4ASQABAAAAHQAAAHRjcG0gRGlnZXN0LCBW b2wgMzIsIElzc3VlIDIAAAAAQABOAIABkakQGscBHgBaAAEAAAAWAAAAdGNwbS1yZXF1ZXN0QGll dGYub3JnAAAAAgFbAAEAAABJAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAdGNwbS1yZXF1ZXN0 QGlldGYub3JnAFNNVFAAdGNwbS1yZXF1ZXN0QGlldGYub3JnAAAAAAIBXAABAAAAGwAAAFNNVFA6 VENQTS1SRVFVRVNUQElFVEYuT1JHAAAeAF0AAQAAABYAAAB0Y3BtLXJlcXVlc3RAaWV0Zi5vcmcA AAACAV4AAQAAAEkAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAAB0Y3BtLXJlcXVlc3RAaWV0Zi5v cmcAU01UUAB0Y3BtLXJlcXVlc3RAaWV0Zi5vcmcAAAAAAgFfAAEAAAAbAAAAU01UUDpUQ1BNLVJF UVVFU1RASUVURi5PUkcAAB4AZgABAAAABQAAAFNNVFAAAAAAHgBnAAEAAAAWAAAAdGNwbS1yZXF1 ZXN0QGlldGYub3JnAAAAHgBoAAEAAAAFAAAAU01UUAAAAAAeAGkAAQAAABYAAAB0Y3BtLXJlcXVl c3RAaWV0Zi5vcmcAAAAeAHAAAQAAAC8AAABUQUtFIFRXTzogVW5pZmllZCBJQ01QIHByb2Nlc3Np bmc6IEEgc3RyYXcgbWFuAAACAXEAAQAAABsAAAABxxoQrd2pzdN8fFVFlLqddPX/JseHAADxE58A HgB0AAEAAAAOAAAAdGNwbUBpZXRmLm9yZwAAAB4AGgwBAAAAEQAAAE1haGRhdmksIEphbXNoaWQA AAAAHgAdDgEAAAAvAAAAVEFLRSBUV086IFVuaWZpZWQgSUNNUCBwcm9jZXNzaW5nOiBBIHN0cmF3 IG1hbgAAAgEJEAEAAAAmAgAAIgIAADwDAABMWkZ1XharHwMACgByY3BnMTI14jIDQ3RleAVBAQMB 9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEz CO8J97Y7GB8OMDURIgxgYwBQ8wsJAWQzNhZQC6YK4wqEwQqASm9lIFQIYBPQLCB3A2AOsDoc+j4g EEkgdGgLgGsgczMDcB3Qb2YfoR3QcG99C4B0BCAKwB3QBaEYIGPgdCwgYnUFQB5wIKBVFAAgE+B2 HdBmCsAtFxggANAfwWcfFnJhbSMGkA3gYXRpAiBzLg8fgCBwB0ADIElDTVCxISRhZHYEAAWweSHw 8GUuZy4h8CCRA6AgEzUfsmcEIHcd0BggbHm/HxYCICMABbEhhSBQcASQ5yTDHkAIYGxkIAADEAnw rnQosCMBAxEoGCFpIbK+cyHwC4AgwArAJNBjKwD5CsApLhz6H5YfsCTAJaP3KIEsVSYEYiAQCkAO sCuh8yZWJSAgVx3QIsMXsCERfyBhHPQksBQQKEEicSCxZecqQCtgLNBnbgWwKHIsV90sUHMBoDRR FBBuLFAjsP0ggm0h8AWxKlEk4CxQJLC7JYAoxWMrYArBIJJsBADfIjEgcCw2MmA4cW4JgCRAjwhg DrAlER+AJ20gNKD9BUBzCHAd0DOwLzEFoCsC/GJlHPQEYCYpLwIDoC8SsS3LLS1KHPoc9H1AsAAA HgA1EAEAAABKAAAAPDMwNUM1MzlDQTJGODYyNDlCRjUxQ0RDRTg5OTZBRkY0MUNENzk0QGJjcy1t YWlsMi5pbnRlcm5hbC5jYWNoZWZsb3cuY29tPgAAAB4AORABAAAAJgAAADxFMUdzS2xELTAwMDZO Zi1Qd0BtZWdhdHJvbi5pZXRmLm9yZz4AAAAeAEcQAQAAAA8AAABtZXNzYWdlL3JmYzgyMgAACwDy EAEAAAAfAPMQAQAAAHoAAABSAEUAJQAzAEEAIABUAEEASwBFACAAVABXAE8AJQAzAEEAIABVAG4A aQBmAGkAZQBkACAASQBDAE0AUAAgAHAAcgBvAGMAZQBzAHMAaQBuAGcAJQAzAEEAIABBACAAcwB0 AHIAYQB3ACAAbQBhAG4ALgBFAE0ATAAAAAAACwD2EAAAAABAAAcweFQpchQaxwFAAAgwDoADrxQa xwEDAN4/r28AAAMA8T8JBAAAHgD4PwEAAAARAAAATWFoZGF2aSwgSmFtc2hpZAAAAAACAfk/AQAA AFQAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089Q0FDSEVGTE9XL09VPUNGLUJBWS9D Tj1SRUNJUElFTlRTL0NOPUpBTVNISUQuTUFIREFWSQAeAPo/AQAAABUAAABTeXN0ZW0gQWRtaW5p c3RyYXRvcgAAAAACAfs/AQAAAB4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAAMA /T/kBAAAAwAZQAAAAAADABpAAAAAAAMAHUAAAAAAAwAeQAAAAAAeADBAAQAAABAAAABKQU1TSElE Lk1BSERBVkkAHgAxQAEAAAAQAAAASkFNU0hJRC5NQUhEQVZJAB4AMkABAAAAFgAAAHRjcG0tcmVx dWVzdEBpZXRmLm9yZwAAAB4AM0ABAAAAFgAAAHRjcG0tcmVxdWVzdEBpZXRmLm9yZwAAAB4AOEAB AAAAEAAAAEpBTVNISUQuTUFIREFWSQAeADlAAQAAAAIAAAAuAAAAAwB2QP////8LACkAAAAAAAsA IwAAAAAAAwAGEDz9ieIDAAcQhgEAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABKT0VUT1VD SFdST1RFOklUSElOS1NPTUVPRlRIRVBPSU5UU0FSRUNPUlJFQ1QsQlVUT1RIRVJTSEFWRUZBUi1S RUFDSElOR1JBTUlGSUNBVElPTlNJRkFMTElDTVBTQVJFQURWAAAAAAIBfwABAAAASgAAADwzMDVD NTM5Q0EyRjg2MjQ5QkY1MUNEQ0U4OTk2QUZGNDFDRDc5NEBiY3MtbWFpbDIuaW50ZXJuYWwuY2Fj aGVmbG93LmNvbT4AAAAZRg== ------_=_NextPart_001_01C71A14.AEF79451 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_001_01C71A14.AEF79451-- From tcpm-bounces@ietf.org Thu Dec 07 11:00:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLfu-0007U9-1z; Thu, 07 Dec 2006 11:00:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLft-0007Ty-Ju for tcpm@ietf.org; Thu, 07 Dec 2006 11:00:41 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsLfm-0003sp-RU for tcpm@ietf.org; Thu, 07 Dec 2006 11:00:41 -0500 Received: from [127.0.0.1] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kB7FxpsP005312; Thu, 7 Dec 2006 07:59:52 -0800 (PST) Message-ID: <45783A73.1060308@isi.edu> Date: Thu, 07 Dec 2006 07:59:47 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Mahdavi, Jamshid" Subject: Re: [tcpm] RE: TAKE TWO: Unified ICMP processing: A straw man References: <305C539CA2F86249BF51CDCE8996AFF41CD794@bcs-mail2.internal.cacheflow.com> In-Reply-To: <305C539CA2F86249BF51CDCE8996AFF41CD794@bcs-mail2.internal.cacheflow.com> X-Enigmail-Version: 0.94.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: cab78e1e39c4b328567edb48482b6a69 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="===============1233823685==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1233823685== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE18DD25642C55589B393C7DC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE18DD25642C55589B393C7DC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mahdavi, Jamshid wrote: >=20 > Joe Touch wrote: >=20 >> I think some of the points are correct, but others have far-reaching >> ramifications. If all ICMPs are advisory, e.g., then some things we re= ly >> on for correct operation would silently fail (redirects, in particular= ). >=20 > I think that ICMP redirects are absolutely advisory. We have lots of=20 > cases where people ignore redirects, disable sending them, or periodica= lly > clear the list of redirect learned routes. I'm not sure what could be > more advisory than that. Maybe I'm misunderstanding advisory. I thought it implied "SHOULD ignore". If it implies "MAY ignore", that seems fine. Joe --------------enigE18DD25642C55589B393C7DC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFeDpzE5f5cImnZrsRAonNAKCeH92gGEdOXpZiPiQscTESuhW5tQCfXCPu uYD9mw1PkvqLOo8aFdokl2o= =drDW -----END PGP SIGNATURE----- --------------enigE18DD25642C55589B393C7DC-- --===============1233823685== 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 --===============1233823685==-- From tcpm-bounces@ietf.org Thu Dec 07 11:03:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLhz-00005C-As; Thu, 07 Dec 2006 11:02:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLhy-0008V3-Bu for tcpm@ietf.org; Thu, 07 Dec 2006 11:02:50 -0500 Received: from c00l3r.networx.ch ([62.48.2.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsLhr-00048L-92 for tcpm@ietf.org; Thu, 07 Dec 2006 11:02:50 -0500 Received: (qmail 35718 invoked from network); 7 Dec 2006 15:50:58 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Dec 2006 15:50:58 -0000 Message-ID: <45783B1A.9080807@freebsd.org> Date: Thu, 07 Dec 2006 17:02:34 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and TCP's reaction to soft errors) References: <7.0.1.0.0.20061207102856.0671d6d0@gont.com.ar> In-Reply-To: <7.0.1.0.0.20061207102856.0671d6d0@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: tcpm@ietf.org, tsv-dir@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > Folks, > > I would like to state my opinion on the question asked by Mark (wrt what > we would do with the ICMP docs if we were to take Matts suggestion for > working on ICMP): > > * Both of the drafts are aiming at Informational, thus just describing > "what is implemented out there". No matter what we end up standardizing, > that will not change what is currently implemented out there. That's one > of the reasons for which I think that even if we got consensus to > proceed as suggested by Matt, both documents should still be moved > forward on the Informational path. From the point of view of an actual kernel and TCP/IP stack developer I can only say that this documentation is invaluable for reference and for interoperability issues. In my opinion having this documented and preserved as an informational RFC helps people new to TCP it to find it and to avoid the mistakes of the past. A new tcp/ip developer or hacker can avoid countless hours of debugging and re-inventing the wheel by just looking at the work already done for them by Fernando and all the other participants to it. Not formally documenting it would just let it slide into obscurity quickly and in a year or two only us 'greybeards' will remember it while the next generation repeats history again. That's just wasteful. This is a perfect application of the "standing on the shoulders of giants" meme. -- Andre (@FreeBSD.ORG) > * In the case of the ICMP attacks draft, one of the goals of the > document is to discuss ICMP-based attacks (other than "proposing > mitigations). And many have argued that it is really needed (e.g., it is > not clear to everybody how TCP MD5, IPsec, etc, interact with ICMP and > TCP... and that's one of the things the draft tries to clarify). > > * There are already a few RFCs, around ten internet drafts (including > one by the IAB), and a few papers referencing it, and it is worth noting > that while we have two documents on TCP-based spoofing attacks > (antispoof and tcpsecure), if we were to drop the ICMP attacks draft we > would end up having no doc describing ICMP attacks against TCP (which, > ironically, are simpler than their TCP-based counter-part). > > * Another thing with the ICMP attacks draft is that it describes quite a > few mitigations that have been widely implemented, and not just the TCP > SEQ check and that of dropping ICMP SQ. Therefore, even if we were to > pull the ICMP SQ and the TCP SEQ check stuff from the document, there's > still more stuff in the document that makes the draft worth publishing. > > * I agree that the ICMP attacks draft needs more work. In the last few > revisions I have been addressing lots of technical comments posted by > many of you on the list. That's why I have not yet completely tackled > those parts of the draft that are still "too prescriptive". This is > going to be the goal of the next revision which, in the event anybody > sends text (it's a wg doc!), will probably converge even sooner than > expected. > > * In the case of the ICMP soft errors draft, we have had discussions for > the last two years, and we didn't get consensus to standardize the > "abort the connection reset upon receipt of an ICMP soft error". But > there are many implementations that already perform some alternative > reaction to ICMP error messages received during the > connection-establishment phase. I think we had already got consensus to > document it. And the draft is very close (if not already) for WGLC (we > bounced the doc a few times with Mark, and I will be able to publish a > revision anytime soon). > > * It is worth noting that we were recently talking about how to > encourage participation of open source projects in the IETF. The ICMP > attacks draft has benefited from the feedback of all major open source > OSes, along the two years it has been around. While we certainly should > not make a decision based exclusively on this point, I'm not sure all > those guys would be happy to provide feedback on future drafts if they > realize that the time they spent during two years contributing to an > IETF doc basically ended up in nothing. > > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Dec 07 11:30:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsM8h-0005ul-68; Thu, 07 Dec 2006 11:30:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsM8g-0005ua-3o for tcpm@ietf.org; Thu, 07 Dec 2006 11:30:26 -0500 Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsM7y-0005AD-Ji for tcpm@ietf.org; Thu, 07 Dec 2006 11:30:26 -0500 Received: from bcs-mail2.internal.cacheflow.com (bcs-mail2.internal.cacheflow.com [10.2.2.59]) by whisker.bluecoat.com (8.13.8/8.13.8) with ESMTP id kB7GTfvn001674; Thu, 7 Dec 2006 08:29:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] RE: TAKE TWO: Unified ICMP processing: A straw man Date: Thu, 7 Dec 2006 08:29:35 -0800 Message-ID: <305C539CA2F86249BF51CDCE8996AFF4017EAFDF@bcs-mail2.internal.cacheflow.com> In-Reply-To: <45783A73.1060308@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] RE: TAKE TWO: Unified ICMP processing: A straw man Thread-Index: AccaGNHkdqfAtVTOSYmqrt3NaUeLOAAA/0cg From: "Mahdavi, Jamshid" To: "Joe Touch" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org That (MAY ignore) has always been my understanding of advisory. --J -----Original Message----- From: Joe Touch [mailto:touch@isi.edu]=20 Sent: Thursday, December 07, 2006 8:00 AM To: Mahdavi, Jamshid Cc: tcpm@ietf.org Subject: Re: [tcpm] RE: TAKE TWO: Unified ICMP processing: A straw man Mahdavi, Jamshid wrote: >=20 > Joe Touch wrote: >=20 >> I think some of the points are correct, but others have far-reaching >> ramifications. If all ICMPs are advisory, e.g., then some things we rely >> on for correct operation would silently fail (redirects, in particular). >=20 > I think that ICMP redirects are absolutely advisory. We have lots of=20 > cases where people ignore redirects, disable sending them, or periodically > clear the list of redirect learned routes. I'm not sure what could be > more advisory than that. Maybe I'm misunderstanding advisory. I thought it implied "SHOULD ignore". If it implies "MAY ignore", that seems fine. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Dec 07 11:51:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMSe-0007GR-RM; Thu, 07 Dec 2006 11:51:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMSd-0007G9-LZ; Thu, 07 Dec 2006 11:51:03 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsMSE-0007vQ-Va; Thu, 07 Dec 2006 11:51:03 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id kB7Go1Vh031255; Thu, 7 Dec 2006 08:50:01 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id D4791568B21; Thu, 7 Dec 2006 11:49:58 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3BEF314B626; Thu, 7 Dec 2006 11:49:43 -0500 (EST) To: Andre Oppermann , mathis@psc.edu From: Mark Allman Subject: Re: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and TCP's reaction to soft errors) In-Reply-To: <45783B1A.9080807@freebsd.org> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: They're Coming to Take Me Away MIME-Version: 1.0 Date: Thu, 07 Dec 2006 11:49:43 -0500 Message-Id: <20061207164943.3BEF314B626@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org, Fernando Gont , tsv-dir@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0940622122==" Errors-To: tcpm-bounces@ietf.org --===============0940622122== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Thanks for the thoughts folks. Let me try to ask a more refined question rather than the pretty open question I asked last night. What I am really wondering about still is how Matt's vision encompasses or does not encompass the two current work items. In other words, in abstract terms if we were going to write one document that said "people do X" without making a recommendation or changing a standard and then we wrote something else that standardized X as OK (SHOULD, MAY, whatever ...) then these would be largely overlapping efforts and we might decide that doing both would be silly. So, it seems to me that we have some WG consensus to take on two tasks. Therefore, I think Andre's point is covered. We will get this information written down. But, I do not think the consensus to work on these items says precisely how to accomplish that task. What I am trying to understand is how the current documents overlap with Matt's vision. Will the documents Matt proposes naturally include the information in the two current documents? Will there be missing pieces that we need to pick up (here or in tsvwg or wherever)? Matt- can you help me? Thanks! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFeEYnWyrrWs4yIs4RAiP5AJ9dFj0bztpKHcR+uye/klQnL7MV0wCcC2lP IGvaZTXZlLq0Ds+l+f5IFQA= =+1Dh -----END PGP SIGNATURE----- --=_bOundary-- --===============0940622122== 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 --===============0940622122==-- From tcpm-bounces@ietf.org Thu Dec 07 12:13:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMnZ-0002C9-1P; Thu, 07 Dec 2006 12:12:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMnQ-00026r-NO for tcpm@ietf.org; Thu, 07 Dec 2006 12:12:32 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsMmV-0002lt-EK for tcpm@ietf.org; Thu, 07 Dec 2006 12:11:40 -0500 Received: from lars.local (p54AD0405.dip0.t-ipconnect.de [84.173.4.5]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 13EF413CF82; Thu, 7 Dec 2006 18:16:01 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 83DC329DED1; Thu, 7 Dec 2006 18:11:32 +0100 (CET) In-Reply-To: <20061207164943.3BEF314B626@lawyers.icir.org> References: <20061207164943.3BEF314B626@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Lars Eggert Subject: Re: [tsv-dir] Re: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and TCP's reaction to soft errors) Date: Thu, 7 Dec 2006 18:11:29 +0100 To: mallman@icir.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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="===============0005497483==" Errors-To: tcpm-bounces@ietf.org --===============0005497483== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-53-373212533; protocol="application/pkcs7-signature" --Apple-Mail-53-373212533 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 7, 2006, at 17:49, Mark Allman wrote: > So, it seems to me that we have some WG consensus to take on two > tasks. > Therefore, I think Andre's point is covered. We will get this > information written down. But, I do not think the consensus to > work on > these items says precisely how to accomplish that task. I think there is value in writing down what is currently implemented, with a statement big red letters that says: 1. the purpose is documentation 2. the mechanisms have not undergone IETF review 3. the mechanisms are not IETF standards 4. the IETF may develop standards-track mechanisms that may differ from what is described here Once we have (4), that should informatively cite the informational documents to "obsolete" them. > What I am > trying to understand is how the current documents overlap with Matt's > vision. Will the documents Matt proposes naturally include the > information in the two current documents? Will there be missing > pieces > that we need to pick up (here or in tsvwg or wherever)? I see the informational documents and Matt's proposal as (almost) orthogonal. One says what is currently out there. The other says what _should_ be out there. Parts may be identical (parts of what's out there is what should be out there), but other parts may differ. What is important is to not confuse the informational documents for the (non-existing) standards-track ones, and word them in a way that makes this distinction clear. Lars --Apple-Mail-53-373212533 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjA3 MTcxMTMwWjAjBgkqhkiG9w0BCQQxFgQUM4RtcIp9Dr0qfkIUzXexxGv6EskwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAD+W8SeolCBW8pKoaxD2 /cCQiL3fSJ63/WenxPRgvebq8D5IkfsU51XtY4w8qF+ZfrtbAPH42opf1lss9nMYQsoGoxziXx6P N1wd1ZcazcpHvWhqLTrNv0W1fHvsXo945i+4i2w5dX81kXIFGPl6tuUOrznjOTlKx4eB1G013x0w ZBi68A+JY/wQuzNmkfJHnSt8+xqVbgzJhUxl7WQDGzfOCSsvlBvl9nb2cATcCRExy6WoxogE2UfD UiaV1X2xXtNMv8lHYpGphxVH/KQLH/V2nHQ4/JTEAGrlve1RMoxA3Xvgacq8dczn7NP5O4eiirrC 6De+9NeuwSbC4TrI5ioAAAAAAAA= --Apple-Mail-53-373212533-- --===============0005497483== 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 --===============0005497483==-- From tcpm-bounces@ietf.org Thu Dec 07 14:32:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOy9-0001Qn-LU; Thu, 07 Dec 2006 14:31:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOy7-0001PU-DX for tcpm@ietf.org; Thu, 07 Dec 2006 14:31:43 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsOwr-0007Pt-NY for tcpm@ietf.org; Thu, 07 Dec 2006 14:30:28 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kB7JUEp5024490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 7 Dec 2006 11:30:14 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id kB7JUE8E051995 for tcpm@ietf.org; Thu, 7 Dec 2006 11:30:14 -0800 (PST) (envelope-from faber) Date: Thu, 7 Dec 2006 11:30:14 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20061207193014.GN47066@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.2i 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: 645960076aa293effd9740db2f975dc3 Subject: [tcpm] Minutes from IETF 67 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="===============1353472948==" Errors-To: tcpm-bounces@ietf.org --===============1353472948== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H14uD12u8nekTETJ" Content-Disposition: inline --H14uD12u8nekTETJ Content-Type: multipart/mixed; boundary="IpgPcFyQO6wM49Um" Content-Disposition: inline --IpgPcFyQO6wM49Um Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sorry to be so late with these. The proposed minutes are up at http://www3.ietf.org/proceedings/06nov/minutes/tcpm.txt . Please have a look ASAP to make sure we've spelled your name correctly and not misrepresented your positions. There's a copy attached. --=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 --IpgPcFyQO6wM49Um Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tcpm-notes.txt" Content-Transfer-Encoding: quoted-printable TCPM meeting / IETF 67 / Thursday, Nov. 9, 2006 (Ted's laptop not working with projector) Steve's presentation and security discussion first, because of scheduling contraints. Steve Bellovin - Towards a TCP Security Option motivation / requirements for a new tcp security option existing tcp-md5 has number of serious problems cryptographically "laughable" - should use HMAC or other real MAC not easy to say "this packet keyed with key X", so at times of key change, receiver may get confused no key management people using TCP-MD5 are generally using ascii strings as passwords We [the IETF] know it [TCP-MD5] is weak, we know it was done incorrectly, it would be wrong to advance in order to advance BGP, we needed a process waiver why not use IPsec? turns out not to work particularly well in the real world protection down at IP layer, hard to get key from user layer plays very poorly with NATs. BGP speakers rarely behind NATs, but can't usually use hardware IPsec given way routers are built today one major brand of router notorious for underpowered CPUs TLS doesn't protect TCP header, very easy to destroy TCP connection by injecting just one packet integrated key management perceived to be too heavyweight for some apps requirements for a new TCP security option must protect TCP header proper crypto key management protecting the TCP header in case of encryption, some portions should NOT be protected (due to NAT, proxies, etc) questions about port numbers, window, congestion-related flags key identifier long-lived connection needs to change keys at some point Joe Touch: key word is "efficient" if there are multiple connections between a pair of machines, should they be able to share some state? joe touch: whole thread belongs under "key id or not key id" not under "we need a key id and here are its properties" steve: not saying anything about format, just suggesting properties, without saying anything about how to do it sctp with tls can get some efficiencies automated key management rfc 4107 ikev2 may or may not be a good choice tcp part should be done here, key management done in security area Tim Shepard: why not use ipsec? you explained it, but I'm wondering if the router design issue is the problem, could we use ipsec, but label the packets with a different protocol number Steve: the problem is in the location of hardware assist on the linecard and then to control plane, real concern is CPU DoS attacks against central processor Tim: isn't this problem no matter what solution we adopt, does our solution have to use linecard hw assist? Steve: we've gotten pushback when we said "just use ipsec" ipsec is descendant of sp3 [as in layer 3, network], developed by dod, we should look at sp4 [as in layer 4, transport] Michael Tuexen: will key management be inband? Steve: unspecified, decision for later working group; ipsec would've been done a lot faster if split out from base wg Joe Touch: clean reason not to use IPsec: impossible to force FIN to clear out SA and rekey Steve: I could call the daemon and tell it [the daemon] to destroy it [the SPI] Joe: between FIN and call, another SYN could come in; fundamentally can't tie key to particular session at transport. Steve: ipsec comes from ip layer and doesn't have strong notion of connec= tion Matt Mathis: when bgp1 was being developed, it was refered to as layer inversion, doing layer 3 function over layer4 TCP; critical to address in this document - TCP liveness isn't appropriate for routing liveness; I'm afraid of using other protocols for rekeying if we don't have connectivity when we lose a BGP session Steve: key id could refer to out of band or cached material, think of TLS session resumption Matt: you're talking solutions, question still needs to be well-posed in document Ron Bonica: clear that we need automated keying, but would like to see this decoupled due to differing skillsets required and timeframes Caitlin Bestler: main concern is whether or not this is truly general, I think it isn't general and shouldn't be solved at layer 4 Steve: there's been a fair amount of rumbling since late 90s over problems ipsec was causing for transport and measurement communities; ipsec is protecting too much and has wrong granularity, TLS is also unworkable Yushun Wang: BTNS working group is trying to solve first bullet Ted: Mark and I liked this draft because it directly addresses why tcpm should be working on this would like to have a design team look at this and come forward with a proposal if the wg agrees that this is worth solving Joe Touch: lot of academic/completeness reasons why I think this is needed; this is cleaner than connection-latching; but fundamentally question is "who needs this" and answer is limited to situations where you may be just as good setting up an IPsec tunnel; I can't make a good case that it's absolutely needed Steve: I'll argue both sides too, talking in saag this afternoon about discription of very sophisticated attack that low-value machine in my lab was hit with, we discovered 2 weeks ago that the machine had been compromised since may, it's out there and I'm not the only one whose seen it; connection hijacking and worse is out there, mac address for over 200 other machines was used by this machine, which was demonstrably capable of hijacking tcp sessions; my concern is "is the market going to buy into this?" Ted: not sure market buyin is requirement Ron Bonica: from customers there is demand Caitlin: might slow down deployment of this, TLS, and IPSec with three competing options Joe Touch: this would not necessarily prevent steve's attack, just help limit its scope in propagating Ted: don't get wrapped around axle of attack or about marketing (hum if there is support for doing the work to advance tcp-level security system) solid hum (hum if you oppose) weaker hum (hum if you have no opinion) similar to opposing volume Assuming this isn't immediately contradicted by mailing list, we'll move forward with design team and coordinate with saag Ted / WG status Blind Attack Robustness (tcpsecure) - new revision out soon, approaching last call ECN SYN stuff - Mark raised questions, Sally will address via simulation SYN Cookies - need to roll in freebsd work, and new version out soon 2581bis - Mark working on implementation reports, powwowed with IESG as to format, should be moving forward quickly Antispoof - should be moving towards 2nd last call, limited to updated sections Lars: TCP-RLCI (presented at last ietf) should be looked at by group for consideration for publication Ted: Mark and I getting brand new cattle-prods for christmas, so we should be better at moving these items through more quickly TCP User Timeout Option (UTO) draft-ietf-tcpm-tcp-uto-04.txt - Fernando Gont Lars Eggert (as author): some confusion as to whether UTO should go experimental or PS, charter had it as PS and got consensus, I don't care as either author or AD as AD, would like to go to experimental Tim Shepard: same here, other than experimental should go to list Received feedback from Gorry Fairhurst, which is where most changes since last presentation came from overview Peers advertise their timeout and adapt local value accordingly Main changes introduced in -03 Rearranged introduction Removed discussion of 2 socket options that were not really relevent Clarified that UTO is disabled by default and has system-wide toggle Enforce minimum of one RTO Main changes introduced in -04 Feedback from Caitlin and Jamshid UTO should be sent in first segment after SYN, information could be lost if using syn cookies Made it clear that if option not included in initial SYN, systems that break are already violating TCP requirement of ignoring unknown options Changes to be introduced in -05 Editorial tweaks from Mark Allman Moving forward We think ready for WGLC Gorry Fairhurst: what was mark's comment on 60 seconds Fernando: RTO could be capped at 60 seconds, might not be doubled forever Gorry: do we agree that you don't have to send options in syn exchange Ted: scope that, not violation of an rfc to my knowledge, does it cause problem - yeah Matt Mathis: lot of language in 1323 about not surprising tcps with new options mid-stream, but that was written when the Internet was a much friendlier place Fernando: 1122 says MUST ignore unknown Matt: a lot of companies have trouble with "if the other end does something stupid, don't make it worse" Ted: you're advocating this in order to get rid of bad stacks? laughter Lars: it might be interesting to use this as a test case to see if fragile stacks are still out there Ted: technical issue is that this is not negotiation, it's advisory. Caitlin: key point is that receiving side may not remember whether you've sent it on syn, and don't want to obligate them to reject if they can't remember David borman: back in days of 1122, big issue was that there were implementations that could successfully handle unknown options during syn exchange but no later, but that was 10-15 years ago, we should lose that old baggage and move on; UTO is good example for adding in middle of connection, because it's not negotiated; I think this document has been through enough hammering for simple concept that it introduces Joe Touch: worth clarifying why you're allowing it to be set in mid-stream, and explaining why it doesn't matter, where for other options it does matter (anything that has to be synchronized with data stream) Ted asks Joe to make sure this is addressed Lars: might want to consider a BCP for what to do with TCP options David: document currently says it should be in syns and in first data packet - implies you don't HAVE to have it in both syns and later Gorry: trying to be clear that I wasn't objecting to way it's done, just want it to be clear Matt: people may argue that implementations that do it later are wrong Ted: think that's an inaccurate reading of SHOULD, do you have alternate wording? Joe: should do it this way, but must allow for it to be done other way Matt/Joe: problem is that definition of should is not precise, and doesn't say anything about backward compatibility Anantha Ramiah: not aware of any TCP that doesn't just ignore option David: only clarification is to say MUST accept UTO option even if not sent in initial SYN Caitlin: except in sense of not resetting, it's still free to ignore it David: absense of UTO in SYNs should not preclude later accepting Ted: we all agree with statement, path is to last call document, someone will suggest text (hum if you think ready of WGLC) strong (hum if you don't) none next week will go to WGLC ICMP attacks against TCP - draft-ietf-tcpm-icmp-attacks - Fernando Gont Overview Describes a few ways icmp can be used to break tcp connections 3 attacks spoofing various icmp messages Well-known issues, but no documented countermeasures Most implementations have some countermeasures, for 10 years at least Joe Touch: we had email exchanges on this; wg agreed to "describe" solutions, not "propose" them Counter-measures (1) Check tcp sequence number included in icmp message - not complete solut= ion Change reaction for hard errors to that of soft errors - within current specifications/recommendations counter-measures (2) Ignore source-quench - violates 1122, but generally accepted Bob Braden clarified in Vancouver that if anyone got Source-Quench to work, then we should still be responding to them Matt Mathis: 1122 is just wrong, understanding has changed since that time Matt's comment is on honoring the fragmentation needed [ICMP message] if there is no progress on connection (wait for RTO) Document Path Adopted for informational, question about whether parts should be standards track ICMP provides easier attack than blind rst attack, whose defense is standards track Moving Forward Need to decide on which way to go info or standard, and whether describing or specifying solutions Proposal (1) Split current document into 2, one std track, one bcp/std track with PMTUD-specific parts (in tsvwg since for all transport protocols) this is probably right thing[says the slide], but sctp, dccp, etc have to agree proposal (2) General informational document in tsvwg, and std track in tcpm proposal (3) Stay as is (on informational) Fernando: personally like option 1 or 2, but not 3 Ted: document covers a lot of ground, some people might have different opinions on parts, and then issue of whether we have something to say about transports in general, 2 axes here (hat off) should be sliced up Matt Mathis: curious if you counted number of rfcs that mention icmp (nearly 500), talking about a lot of work, not a small project Ted: restricting to tcp is much smaller Matt: consensus that something should be done, old fraternity joke that "we ought to" means other person, somehow need to start down this path, answer to tcp part may change a bit, state direction and all people using icmp need to consider implications for their own protocol Ted: do you want to articulate vision for icmp here or in tsv? Matt: belongs in TSV Ted: putting consistency check into tcp is small and we can do Matt: small document should begin us thinking about bigger problem, people have inconsistent notions about how icmp should behave Joe Touch: strongly in favor of splitting up into component parts, vetting is simpler, source quench first Ted: would have more boiler plate than text Joe: take it to ISOC, would love to apply header compression there; with regard to individual solutions, unlike rst doc, signals from icmp are not bound to come back within any window, no rule about issuing or receiving icmps within some window, don't want tcp in odd environments to break, maybe more than 4 documents, some may be informational "here's what people do", then we can talk about what to standardize fernando: ICMP is out-of-band signaling, why in case of RSTs are they required to be in window, but not ICMPs Joe: ICMP is not comming from other end of connection. Joe: want to bundle based on semantics Ted: he wants to argue about the issues separately so long argument about some issues don't slow down source quench (really the whole doc.) David Borman: good idea, comment on ICMP - you shouldn't be getting random messages, only in response to sent packets, trying to verify that received ICMPs are in response to something you actually sent Ted: right, it's a really good idea David: if you accept that, how do you do that, and is sequence check good/sufficient, what if router slow path causes delay and it shows up later, but in general idea is sound and good, but we get into is this the right thing and is it always accurate; could also have general purpose document with TCP stuff, and separate with SCTP Ted: Randall tells me SCTP ignores ICMP Randall/Michael: except for PMTU, and Proto Unreachable David: TCP spec doesn't talk about ICMP, but 1122 does Ted: proposal - go to TSVWG with lance in hand say "here is unified view of icmp that all transports should adopt" David: come up with "this is what we're going to do for tcp", and structure into generic and tcp-specific parts within same document Ted: still need to break mitigations into separate documents David: can still be split up, within each mitigation include a general pa= rt Ted: should that go on here or in TSV? David: split-it up and continue here, becomes prototype that other things can reference and use Matt: like using TCP document as example for other protocols =20 Matt: RTT through control path of router may be longer than end-to-end RTT, result is valid out-of-window ICMP Fernando: if error really is hard-error than later packets will generate more that will be valid Matt: one thing missing from document is with PLPMTUD, would like to capture message from probe and you get only one, which you can be way past in window; I used to do measurement using ICMP, but implementations are written for clarity, not performance or robustness Anantha: thinking on ICMP processing, this draft makes it more robust, why are we even discussing things that may be implementation specific and vary from system to system Ted: one of issues is that in earlier versions it was put forth as security mechanism (hard guarantee and not hint - concerned with false negatives), discussion that has to be had Gorry: as DCCP chair, general document is useful, whole bunch of little ones on tcp, whole bunch on dccp, sctp, etc; if we're talking about source quench, we can all agree quickly Ted: I hear what you're saying, this group's ability to more forward isn't happening due to it all being tied together Gorry: I like slicing, just make slices address max number of wgs Bob Braden: proceedural problem, issue for tsv at least, who should lay down general principles and direct particular wgs to fill in details, apparent problem is addressing at lower level rather than higher; whatever TSV decides to do with it Ted: put this on hold [in tcpm]? Bob: present it to TSV and let them decide what to do Ted: not move forward here? Bob: right Lars: comment on jabber from John Heffner: trying to shoehorn ["]real["]security into ICMP handling is difficult (long comment, see jabber log) Joe Touch: backs up Bob Braden, suggest TSVWG continue with it split up, and which ones to do in tcpm or there Bob: in response to Heffner, whenever I hear anyone talk about real security I worry, problems come from people who use icmp (transport layer), making recommendations on wringing as much security as possible out at transport may be helpful Ted: Took away [from Heffner's comment]: standards docs are not good at talking about corner cases and tradeoffs Joe: could impact something legitimate, if misinterpreted as attack; if in fact doing validation check, that's one thing, if security issue, take to SAAG and ask if it provides any security, proceed after [if] laughing stops Lars: John had "real" in quotes laughter Fernando: keep in mind that ICMP is unreliable after all, many many reasons they could be wrong Dave Borman: if all ICMPs get lost, TCP should still work, they provide good information that allow things to progress faster, losing potentially good information, greyscale as to how much we're willing to give up benefits for risks Lars: with hat on, going to TSVWG would be totally appropriate Fernando: I have something I could submit, not finished, but close Lars: we'd look at agenda request favorably Ted: non-binding hum, try to measure room 1) stay with what we have 2) work from tsvwg, stop here until that happens 3) split here and work here with generalization sections Joe: 4th, take it to tsv with big question, or start there with split doc, not mutually exclusive Dave: do we split or not is separate from does it go to tsvwg agreed by room (hum for do we take to tsvwg) medium hum (hum to continue here bottom up) weak (don't care) NONE (in favor of splitting) medium (presenting unified as stands) NONE Advancing F-RTO to the standards track - Max Hata FRTO status Experimental RFC 4138, august 2005 Several known independent implementations Several experimentations Outcome: sucessful and straightforward, performance excellent, no adverse issue reported Will prepare some summary of good things, analysis of conrner cases, and make sure it will not be harmful Recommendation for drafting new RFC Focus only on algorithm and tcp Leave pieces for sack and sctp as experimental Plan on submitting by march 2007 Ted: main reason for this presentation is for people using or who would like to help to come to him or Pasi, bunch of good solid data, would like to happen quickly. --IpgPcFyQO6wM49Um-- --H14uD12u8nekTETJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFeGvGaUz3f+Zf+XsRAt8hAKC2UlLFTFD99tSMJjmSazWc0/KzLQCgpjWh /u6iki/wp7dUokSiDibrIl0= =nwCY -----END PGP SIGNATURE----- --H14uD12u8nekTETJ-- --===============1353472948== 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 --===============1353472948==-- From tcpm-bounces@ietf.org Fri Dec 08 08:48:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsg4J-0004Sy-Vg; Fri, 08 Dec 2006 08:47:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsg4J-0004St-H0 for tcpm@ietf.org; Fri, 08 Dec 2006 08:47:15 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsg4I-00029V-PA for tcpm@ietf.org; Fri, 08 Dec 2006 08:47:15 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id kB8DkpI3019510 for ; Fri, 8 Dec 2006 15:46:52 +0200 Date: Fri, 8 Dec 2006 15:46:51 +0200 (EET) From: Pekka Savola To: tcpm@ietf.org Subject: Re: [tcpm] Future of the ICMP docs In-Reply-To: <45783B1A.9080807@freebsd.org> Message-ID: References: <7.0.1.0.0.20061207102856.0671d6d0@gont.com.ar> <45783B1A.9080807@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.6/2302/Fri Dec 8 01:43:00 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Thu, 7 Dec 2006, Andre Oppermann wrote: > In my opinion having this documented and preserved as an informational RFC > helps people new to TCP it to find it and to avoid the mistakes of the > past. A new tcp/ip developer or hacker can avoid countless hours of > debugging and re-inventing the wheel by just looking at the work already > done for them by Fernando and all the other participants to it. Not > formally documenting it would just let it slide into obscurity quickly > and in a year or two only us 'greybeards' will remember it while the next > generation repeats history again. That's just wasteful. I fully support this view. The ICMP soft-errors and attacks (preferably, all of it; splitting up just takes energy and will take more time) needs to go out, sooner the better. This has already dragged on too long (years). More general standards track work on ICMP will be of longer timescale (just to get agreement on the right approach and to get the details right will take a number of years), hence it should not block work that has been going (and implemented) for years. Unified ICMP work should happen in TSVWG or in a new WG. To gauge community interest (and tentative consensus) on this, it might not be a bad idea to organize a BoF on the topic (not necessarily aimed at creating a new WG). -- 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 Fri Dec 08 09:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GshCH-0007TJ-SL; Fri, 08 Dec 2006 09:59:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GshCG-0007T5-Vu; Fri, 08 Dec 2006 09:59:32 -0500 Received: from mailer2.psc.edu ([128.182.66.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GshCE-0007vY-5p; Fri, 08 Dec 2006 09:59:32 -0500 Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer2.psc.edu (8.13.8/8.13.3) with ESMTP id kB8ExMl4008937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Dec 2006 09:59:22 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id kB8ExLxU005681; Fri, 8 Dec 2006 09:59:21 -0500 Date: Fri, 8 Dec 2006 09:59:21 -0500 (EST) From: Matt Mathis To: Mark Allman Subject: Re: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and TCP's reaction to soft errors) In-Reply-To: <20061207164943.3BEF314B626@lawyers.icir.org> Message-ID: References: <20061207164943.3BEF314B626@lawyers.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: tcpm@ietf.org, Fernando Gont , tsv-dir@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Sorry, Matt hasn't decided what his vision encompasses... My plan (for me) is to re-read all of the recent material, and try to assemble a "master outline" of everything that I think we need to consider including in some future ICMP document. I would like to reuse as much of Fernando's text as possible, but probably reorganized into different documents. Publishing "as built" documents is generally a good thing, especially if they can be viewed as prototypes of future standards. However some cases are not good, such as if they cause implementers to invest in code that is not part of the correct solution. I don't think that is the case here. But I don't have my head around enough of the problem yet. One thing that would be a huge help - if somebody could start on an inventory/bibliography of all RFC's that mention ICMP. This will become one section of either the principles document, or a non-RFC-track planing doc, and then eventually the basis for the "All ICMP updates doc" This bibliography is critical to understanding the big picture. RFC number: Title: RFC status: (std/informational/obsolete, etc) Extent of ICMP language: (incidental, significant, primary) (Extent which the RFC is about ICMP vs some other protocol) Protocols: ICMPv4, ICMPv6, both ICMP types mentioned: echo, redirect, etc or classes such as "errors" ICMP roles: generation, reaction, request/response, translation/conversion, other For the first pass, I just need to know about RFCs that are current standards or standards track. We eventually need to do this for all non-obsolete RFC and all mature ID's..... Fernando, are you up to this task? Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Thu, 7 Dec 2006, Mark Allman wrote: > > Thanks for the thoughts folks. Let me try to ask a more refined > question rather than the pretty open question I asked last night. > > What I am really wondering about still is how Matt's vision encompasses > or does not encompass the two current work items. In other words, in > abstract terms if we were going to write one document that said "people > do X" without making a recommendation or changing a standard and then we > wrote something else that standardized X as OK (SHOULD, MAY, whatever > ...) then these would be largely overlapping efforts and we might decide > that doing both would be silly. > > So, it seems to me that we have some WG consensus to take on two tasks. > Therefore, I think Andre's point is covered. We will get this > information written down. But, I do not think the consensus to work on > these items says precisely how to accomplish that task. What I am > trying to understand is how the current documents overlap with Matt's > vision. Will the documents Matt proposes naturally include the > information in the two current documents? Will there be missing pieces > that we need to pick up (here or in tsvwg or wherever)? > > Matt- can you help me? > > Thanks! > > allman > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Dec 08 11:28:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsiZt-00011o-Op; Fri, 08 Dec 2006 11:28:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsiZr-00011O-O7; Fri, 08 Dec 2006 11:27:59 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsiZn-0006Bx-Ee; Fri, 08 Dec 2006 11:27:59 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kB8GRgK0021553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2006 10:27:43 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kB8GRgVI015172; Fri, 8 Dec 2006 10:27:42 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kB8GRbCD014991; Fri, 8 Dec 2006 10:27:42 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 08:27:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] Future of the ICMP docs (ICMP attacks against TCP andTCP's reaction to soft errors) Date: Fri, 8 Dec 2006 08:27:41 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774519@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Future of the ICMP docs (ICMP attacks against TCP andTCP's reaction to soft errors) Thread-Index: Acca2aGgQX9Ej/EnTL6rWgIwt2YpzwACFWpA From: "Templin, Fred L" To: "Matt Mathis" , "Mark Allman" X-OriginalArrivalTime: 08 Dec 2006 16:27:41.0849 (UTC) FILETIME=[C8968890:01C71AE5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tcpm@ietf.org, Fernando Gont , tsv-dir@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org FWIW, my take is that there is value in documenting operational issues for ICMP as informational in the near term - or, at least having an agreed-upon plan of action for moving forward. We already have RFC2923 and possibly others as useful examples that document as informational certain operational aspects of ICMP. The other thing to consider is that the operational issues would not go away were we to decide to abandon efforts; the subject would simply come around again at some later point in time. I don't care so much what form the documentation takes or where the work is done, but if there are operational issues and we already have a good head start on understanding them, why not see the work through to a useful conclusion? Thanks - Fred fred.l.templin@boeing.com =20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Dec 08 16:27:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsnEq-00085r-Fx; Fri, 08 Dec 2006 16:26:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsnD5-000750-7C; Fri, 08 Dec 2006 16:24:47 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsnCK-0006xW-IB; Fri, 08 Dec 2006 16:24:01 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id kB8LNscF014102; Fri, 8 Dec 2006 13:23:55 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 688145757AE; Fri, 8 Dec 2006 16:23:50 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 799D114CB41; Fri, 8 Dec 2006 16:23:34 -0500 (EST) To: Matt Mathis From: Mark Allman Subject: Re: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and TCP's reaction to soft errors) In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: They're Coming to Take Me Away MIME-Version: 1.0 Date: Fri, 08 Dec 2006 16:23:34 -0500 Message-Id: <20061208212334.799D114CB41@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tcpm@ietf.org, Fernando Gont , tsv-dir@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0973329563==" Errors-To: tcpm-bounces@ietf.org --===============0973329563== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > My plan (for me) is to re-read all of the recent material, and try to > assemble a "master outline" of everything that I think we need to > consider including in some future ICMP document. Thanks. That would be very useful. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFedfWWyrrWs4yIs4RAmvjAJ97cguXlyB+dr44ohq86+qlPEKWXACghpht qIpipyrNFAGDn1GzzVCr6MI= =0ZIE -----END PGP SIGNATURE----- --=_bOundary-- --===============0973329563== 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 --===============0973329563==-- From tcpm-bounces@ietf.org Fri Dec 08 22:44:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gst82-00062i-GT; Fri, 08 Dec 2006 22:43:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gst7z-00062T-S7 for tcpm@ietf.org; Fri, 08 Dec 2006 22:43:55 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gst7y-0003Fu-GM for tcpm@ietf.org; Fri, 08 Dec 2006 22:43:55 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 15E47F0C407; Sat, 9 Dec 2006 00:43:45 -0300 (ART) Received: from fgont.gont.com.ar (157-184-231-201.fibertel.com.ar [201.231.184.157]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id kB93het9020526; Sat, 9 Dec 2006 00:43:43 -0300 Message-Id: <7.0.1.0.0.20061208221851.06dbabe0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 08 Dec 2006 22:25:04 -0300 To: Matt Mathis , Mark Allman From: Fernando Gont Subject: Re: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and TCP's reaction to soft errors) In-Reply-To: References: <20061207164943.3BEF314B626@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Sat, 09 Dec 2006 00:43:44 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 11:59 08/12/2006, Matt Mathis wrote: >One thing that would be a huge help - if somebody could start on an >inventory/bibliography of all RFC's that mention ICMP. > >This will become one section of either the principles document, or a >non-RFC-track planing doc, and then eventually the basis for the "All ICMP >updates doc" This bibliography is critical to understanding the big picture. [....] >For the first pass, I just need to know about RFCs that are current standards >or standards track. We eventually need to do this for all non-obsolete RFC >and all mature ID's..... > >Fernando, are you up to this task? Yes. As you mentioned, I will start with the std track RFCs, and will try to get the document ready ASAP. From then I will move on. Do you think we should go through all the RFCs (i.e, std track and non-std track), and then move on to the ID's, or go through the std track RFCs, then through the IDs, and then through the rest of the RFCs? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Dec 09 15:52:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt9AA-0007QO-SM; Sat, 09 Dec 2006 15:51:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt9A9-0007Lk-RJ for tcpm@ietf.org; Sat, 09 Dec 2006 15:51:13 -0500 Received: from mailer2.psc.edu ([128.182.66.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt9A7-0007lo-IM for tcpm@ietf.org; Sat, 09 Dec 2006 15:51:13 -0500 Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer2.psc.edu (8.13.8/8.13.3) with ESMTP id kB9KouYR008214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Dec 2006 15:50:56 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id kB9Kotjv008172; Sat, 9 Dec 2006 15:50:55 -0500 Date: Sat, 9 Dec 2006 15:50:55 -0500 (EST) From: Matt Mathis To: Fernando Gont Subject: Re: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and TCP's reaction to soft errors) In-Reply-To: <7.0.1.0.0.20061208221851.06dbabe0@gont.com.ar> Message-ID: References: <20061207164943.3BEF314B626@lawyers.icir.org> <7.0.1.0.0.20061208221851.06dbabe0@gont.com.ar> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Well, there is not much point in going through deprecated and other obsolete RFC's. I think we should at least know about Informational RFC's that mention ICMP. What tools have you been using for version control and formatting you ID's? Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Fri, 8 Dec 2006, Fernando Gont wrote: > At 11:59 08/12/2006, Matt Mathis wrote: > > >One thing that would be a huge help - if somebody could start on an > >inventory/bibliography of all RFC's that mention ICMP. > > > >This will become one section of either the principles document, or a > >non-RFC-track planing doc, and then eventually the basis for the "All ICMP > >updates doc" This bibliography is critical to understanding the big picture. > [....] > >For the first pass, I just need to know about RFCs that are current standards > >or standards track. We eventually need to do this for all non-obsolete RFC > >and all mature ID's..... > > > >Fernando, are you up to this task? > > Yes. > > As you mentioned, I will start with the std track RFCs, and will try > to get the document ready ASAP. From then I will move on. > Do you think we should go through all the RFCs (i.e, std track and > non-std track), and then move on to the ID's, or go through the std > track RFCs, then through the IDs, and then through the rest of the RFCs? > > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Dec 09 18:17:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtBQk-0002De-Qp; Sat, 09 Dec 2006 18:16:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtBQj-0002DY-Sv for tcpm@ietf.org; Sat, 09 Dec 2006 18:16:29 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtBQf-0003j9-HN for tcpm@ietf.org; Sat, 09 Dec 2006 18:16:29 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 92659F0C445; Sat, 9 Dec 2006 20:16:29 -0300 (ART) Received: from www.gont.com.ar (localhost.localdomain [127.0.0.1]) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id kB9NGPFl013322; Sat, 9 Dec 2006 20:16:26 -0300 Received: from 201.231.184.157 (SquirrelMail authenticated user fernando@gont.com.ar) by www.gont.com.ar with HTTP; Sat, 9 Dec 2006 20:16:27 -0300 (ART) Message-ID: <52111.201.231.184.157.1165706187.squirrel@www.gont.com.ar> In-Reply-To: References: <20061207164943.3BEF314B626@lawyers.icir.org> <7.0.1.0.0.20061208221851.06dbabe0@gont.com.ar> Date: Sat, 9 Dec 2006 20:16:27 -0300 (ART) Subject: Re: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and TCP's reaction to soft errors) From: fernando@gont.com.ar To: "Matt Mathis" User-Agent: SquirrelMail/1.4.7 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [127.0.0.1]); Sat, 09 Dec 2006 20:16:28 -0300 (ART) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tcpm@ietf.org, Fernando Gont , Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Matt, > Well, there is not much point in going through deprecated and other > obsolete RFC's. Yep. I was meaning Informationals. > I think we should at least know about Informational RFC's that > mention ICMP. Okay. Will first go through the std track ones, then through the Informtionals. > What tools have you been using for version control and formatting you > ID's? I use the online tools at http://xml.resource.org. Kindest regards, Fernando Gont _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Dec 11 15:51:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts79-0001so-5o; Mon, 11 Dec 2006 15:51:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts6b-0000t9-7m; Mon, 11 Dec 2006 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gts6Z-0006AR-TG; Mon, 11 Dec 2006 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id C40F42AC63; Mon, 11 Dec 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gts65-0007hd-GR; Mon, 11 Dec 2006 15: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: Mon, 11 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-syn-flood-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: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP SYN Flooding Attacks and Common Mitigations Author(s) : W. Eddy Filename : draft-ietf-tcpm-syn-flood-01.txt Pages : 20 Date : 2006-12-11 This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-syn-flood-01.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-syn-flood-01.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-syn-flood-01.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: <2006-12-11134058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-syn-flood-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-syn-flood-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-11134058.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 Dec 12 09:16:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu8Px-0000Gs-4l; Tue, 12 Dec 2006 09:15:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu8Pv-0000Gh-SK for tcpm@ietf.org; Tue, 12 Dec 2006 09:15:35 -0500 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu8Ps-0005YX-Vy for tcpm@ietf.org; Tue, 12 Dec 2006 09:15:35 -0500 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id A281BC224 for ; Tue, 12 Dec 2006 09:15:22 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kBCEFMiV026694 for ; Tue, 12 Dec 2006 09:15:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kBCEFMNw005934 for ; Tue, 12 Dec 2006 09:15:22 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 2OmSGC1y-ZVt for ; Tue, 12 Dec 2006 09:15:21 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kBCEFLtF005927for ; Tue, 12 Dec 2006 09:15:21 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 2645A4FD8F; Tue, 12 Dec 2006 09:13:48 -0500 (EST) Date: Tue, 12 Dec 2006 09:13:48 -0500 From: Wesley Eddy To: tcpm@ietf.org Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-syn-flood-01.txt Message-ID: <20061212141348.GB19725@grc.nasa.gov> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i X-imss-version: 2.045 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Dec 11, 2006 at 03:50:01PM -0500, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : TCP SYN Flooding Attacks and Common Mitigations > Author(s) : W. Eddy > Filename : draft-ietf-tcpm-syn-flood-01.txt > Pages : 20 > Date : 2006-12-11 > > This document describes TCP SYN flooding attacks, which have been > well-known to the community for several years. Various > countermeasures against these attacks, and the trade-offs of each, > are described. This document archives explanations of the attack and > common defense techniques for the benefit of TCP implementers and > administrators of TCP servers or networks. > A gzipped rfcdiff output between this version and the previous version is attached. The changes are pretty small, mainly consisting of: . added short description of the new FreeBSD use of the Timestamp field to extend the amount of bits available for SYN cookies, and enable window scaling, SACK, etc. in conjunction with SYN cookies. . clarified document scope only includes SYN flooding directed at over-running a TCP stack, not attacks aiming to over-run a network ("lower" rate attacks, not high rate attacks) . added discussion of applications where the passive side sends the first data and how SYN cookies can be problematic for these applications -- Wesley M. Eddy Verizon Federal Network Systems --/NkBOFFp2J2Af1nK Content-Type: application/octet-stream Content-Disposition: attachment; filename="syn-flood-00-01-rfcdiff.html.gz" Content-Transfer-Encoding: base64 H4sICM+QeUUAA3N5bi1mbG9vZC0wMC0wMS1yZmNkaWZmLmh0bWwA7F1tc+M2kv6eX4HVVl2S Kr1Ytsf2eDyu8vglmd1kMjV2kt26ygeIhCScSYIhQMvK1f336wZAipJoCbIx1Hi8ScWxLJLd eNBo9BuaJ3+7+OX85t8fL8lYxRH5+Ou7n96fk1an1/t977zXu7i5IP/68ebnn0i/u0NuMppI rrhIaNTrXX5okdZYqfS415tMJt3JXldko97Np949PquPN9tfO6pyZzdUYev0mxP85vRkzGh4 evK3Tof8wBKWUcVCMpiSbBiEfDgEsnt7x+WnDulIFYpc4W+aYRWnvX4vzOhQdThTw44K0rgj p0lnGAkRdnZ2uupe6ct2V13W15d1OoaVk/WoaFD2uzv9OVRa5LR8yPVUKhYfk594kt+TgA5Y ljDVvWPZrVQ07MIHsts96B51djsHRwfk7/ConJGzfET6B6S/d7y7e7x/RH69OSe7OzuvCMeL fvjwa888sCDzq+TJiNDJ7THp5TLrDXjSG+mPcC05m9ySvW6/+2rheoSzcoP5qDH+Dm/D33LF I/k9sHjU7S/cPVm43X7GO/WvZMcQJN8QchIzRQnKSYf9mfO7t61zkSiWqM7NNGUtEphPb1uK 3ase4v2GBGOaSabecik6R0evXnf6rTXPulbTiNU+MZCydXqiuIrY6YUZ5jpp6ay6REvKSc88 EJnSjEmkTxTQr5LVX5OBCKf4//8lMc1GPDkGePbZ/Rv7sZPx0VgdE5or8Yb8n7lHZYSYe4o/ hMUfJmOuWEemNGDHJM3YGzKEAXeGNObR9JjEIhH6yzcERE3xgEYdGvERkFUitRdL/hdDNo4O WPymoDAuKCxfUnDRlTGNoqVr9CXmL4jDMeEKSAYLnP3GspAmtE1+ZNEdQ87aRMLa6UiW8eGM RsSGSvMxoMHtKBN5EnYCEYnsmPz98vJydqEG7oELr66uZhdqmXzgwvPzyoXRIBLBbf2F767e VUivuPDq6mh2IU9gdKr+wqM5HlnEFKu/8KzK453g4UODuaryiOvACceIJ2yQPUD67Gz+wkTA hfbbjIVvHgR/TkIOUUJwYRSyqOfuDUlpGIJGgUvIbno/o8QinkouHVhCYTFDrb344uJiUWBW XD0Pi5njFZe/vni9JBIreTlYEowVl+9UWbfiseLyo7PK5bDDKNm2/wflMft1vGLk5WzAXJAd +7STnl7Upyc9vVd/A3/7Rv8w/56gejPaWdEBKMGByEKWvW3tgCZmUWSfWX5G3WQ/27v0A05A 4w1Gmpu3LQFb6oih2h4DWfwB//1XMpDpm3XK21xV3kTcb+/X3G5+6anMqnJkN4NvQhJEVMq3 LbMiWuROizXofpG28IZw7iKQ0dlfNU9z32uxrLnt4WcjR09m6ANTE5Hdkt/hB+7qP4BEpGSD f37vksswnK4dmG9CTQH0HuwItNk6Fyg1K/iDnY3/JRJyxUDyaUSKARsTUK4FyDehRwF0ekJJ QmMwYHC73NnZ6eO11BOgWjm2Ti/vU54xeUz+cQKKICm+NtqtdUqTnGZT0j9qo817uF4y/pFH cPkh6Ch42qm+62AF3Ku5MCq5dZonjPT7rixcsIDFYNyTo1oumhLWL069VDG6Of9Irv/9gVyh qkUVcKYU7EGS0CQk5yIGo5X8DD7UiKIftX7BeHi2nzWy+xnWSL2Yrdi5apfSjpXG9avhafSK RdNfoPdi5f4a7KxcEjEEW4tL8jOLxVoeV9zzYnGEm99NicwHMVcK17WGZn6rbBNGgzG6zmOR gTsC7rAE1x/NXKpAAay3TbxSaRAamqbgYWuDO6UY7iDAmlBj2Ifef/yEl/NYC9RkzIH3McPv JfwPRkcnNGMuyHgj0iAwY3oHPghjCfIy4VEEH0jIZRAJycAPwl0BpqyO6wELRMycdh9/VJqU GZySOm55QmgQCAzPBHgBOInXLMDtkhzgEN7BFnv4uuskMp5ovGS1N699YCkhotZ3CkWQx1r5 6M2ClReTy2QEVMBBSEYuE+WNSIPA3FB5S65EBgL03fvLm6vvQawM61SaNYcfi1FghCOVXUI+ CMW0rnbBxRcNH7B4ltlasrOoyyij05axcs3945m5m9JMdSK0dnUE+FTe8jTV26XAaH0yYgSH br48YfEpbBjwN3CikDbZ2zvpwR+tqbwYmpmnknmkEvrWoDD9MZ2iasvTEJNVbbQHIhrgb7g5 DqRA+1snscxOOVtM7iaJTzoNrk/FYwZr4b1CA4AnYD5kIs04xaUhSC7ZstaRMK4hyxhsCi7A +KHQICQxsAb8RThpKMVcqwkW20kDjZEgiy0dxoE9EsYzAvNSdlsucDz96S95n72BnS3iUuEu F+RZhgbuovgEgCCsQjBdADZYbo6byJOe3KS1PMvfo6uvM/j4S6/Pww4dSJXRQEmMjDtZf494 3H8E0IjJQgz4ekxDMSEXPAMjWWSc+RDFp9DYslBKzWsX6wMeLYl1z/g6xG8pLrn3eeKSN8vB EePrMR1RJ+DMrQnsV2Pkh6tm8glE5+P49RS/jnl/BEPnIp2aPDi4LNzB6nrohheLINw8w+S7 8++1ii095GsRgMKZku8wCfS9k67a/GkvFvsza0OsZWzxwheLWKFAC/eQhEwGGR/AZl9kzoZF 5oyazFm7iFkWQU43O8MTkQaBmbAo6twmYpKg94SBrkDEcZ5wWHFDDNeyO51mnzKaYZDnN5px kTsFiJ/46AZBCESO2iZmVObgGxI6orCBKuRZstlsYUgChwGrKmQdMRzq4CAmRtouePij8jUG 1vY2DXnt2pBX/9UGgTWPVLwG1m50hgnm2Vbzrl9gD97xktV8v6uj+pkIc5NX6W78L9lzWcte CTUI0C7QNcUh5ELvT+nG3JN9F4C8EmoQIOS8Dz9/5FIJcNceM7FOAHkl1DBAuyaogmyDAvol xUMrOLveAfJGqEGA9rqkqLm6YEMGjrjcdHKxjm49QF4JNSpBe1ryr3ikdBp1c9l3A8groYYB Qsl/nwSYckXG34EijcToMwDkjVDDAO3Bz08Mtl/kGryrzqfL88v3v11ekBses2zdVLsD5I2Q n7Dm/ucqt9zr7sNP9FPPwddgj1grtWHPo82KMD1zUcRBX2+pNNOO6VUxJiFu+SPU9GtXYfVG yI+wvvp8wnqAttN0kPGQnGEKHKVlg/HWymp/w4phv1yUZcRbqCOeH9Wh3jQzNgFf2BSRf8zE vbM8ecLWJxdfBrb76BQlNJpKLjdcmauxXRzVSmx9c1Fiu7tNbF/BqK5ZkGcYXjwXieSh9Rac 12M9tnubYOubixLb/W1ie4ASE2AoN2LhiJkSKx9yuziqldj65qLE9tU2sT3UkaShyGIQkzsG pqat1HIfmwdsfXPxZWCL/5zpIwvfSnIWhlj35UVuF0e19mSRTy5KbA+2ie1Z91GWZi2e1QuW RrUS20UuaoGqBCDts5+miw+3LdOYG48iFqicRmgUpcDX1B72K/LoeJ7qAR1ZL9OLLtJamfbJ RYHt7qKV+GKzGYsZhrUMPnTDi0WQmMq/msy7PpxFQpbouuEhAdm74wEjMQMtHRI6HOKxHLh8 LKRDKs43oQYB0sf3sjzRNQrIHcuwQlqXPmJOHsdlh6LoLSatwzuaKMyMmnMxLuB4I9IgMNgq hJGMYWoVMw7IOig4tJCkqV4QMdO1+DCLiuGZyIDxOz31KAkuuPii0SQsbKSLW5QAFlKRKTO5 YyrNUcA0V4Qnttzjp/fXN5cfzDDtNA+o5IETNj4JNQgQ+HsUVz1wxu7TSHBljtMO2JjecZjT wZQENDcdy/Syx0tBBihPCNDJR2MXeDySaXxRoWQPxCiXMJvRsBOIJDGnIO1pYjy3wfRhvARZ liLP0A/RbY7U+oPknuk0CA+T2D6IyzFJ2AT4GHFY+ziSCutO1ZQbPehl2wewZur27VLPrCli c7MNPBFpEJgYT27rwjxTkFayKgZ6Aw/xKBUyOuGRPoCX2DY8QufoReZkNfmj0iA0yChLwo42 2TAkRZJcN78BW8XYdbJyNj5kdywCdkN9X8hAV09Z6AKOTzpNWpQCpvV2wRqOMOTBjLV7h1s0 uOSpPakH2lefvFHTTUxKb1T8JLoOPk+iyyiKWU3oBPb9CHzsO8ojXf+3UFPa1ld9ujpHM3sp HlK4+rDMNvH1/TJRePoiiaZbi6PUwgLPBCHBfqJ3WIdcsleWdDMz/tqb7/IIe/cOeARKuw0P yoq7ZT4awYasV+aqk88zwFfRK+Cbo4cHXOESdk/jFOYjFiD/plAKbSBYGhhy3GbQKi6bTxHF gnHC/8yZcXHQ5+HINQ7YJEqsBZ/mWSokKzoCrUeuFicgPizLf/4bhHL3aPfwj9l2AzNeO1H1 LG8FvPJEgbH3JTAlh1MwbdXY6jJACXYKqRuMJPDTxvGxHbOTwG00EQ/wsxVodJ/je1XEEDBs EOgBILPfwagShotIFF99X5lWJ2TcQF7Jx1aAqawyNc7Q3dOqBPyCJKQZjAJPBunwlHV38Mhr YPOVuAIc1huQWQPxWja2gs0wz3RrAG1Joujr9i6XN1dGK+h5jYhMWcCHPLDJW/wmw47bmQln O8GzFuQ1vGwFHpD20JSTgpmJJyO4jE1vHJErZN1MYQDG5pJKcDvN6obww4xswV5wGdYG8Hxh nPv55wsdXK1ZMH9Ujyc2BEujCD3uIMdaatBfdaf2yDATMUjr9ozXR1tCPAn5HQ8xX1d4ltg2 xfa4QwC+lRiBxpWJLlRbG5aw+miit/qQJVu02R897CLromMrVJWKh+Ckqyns2r8MQQDaZAz+ JUlhkpnq4Hs4iil/hmM2EU6ajZgy7q+JnOD86vEVCRgU7ICmpSMBShg/BvDhGY660pOwiCCJ 4tAIrm2sFuDYfE/m2M3SLugZTM9wyHZije2C/iutMeW1Sz4tNnGdidQblLE4+HMU8EJ54yFq pm0otEWFMiMdg05jSdEQqziAbZNKuiMWngd9hsO23QjLmIw0q5uqPCuypXaFSxx6qJuEZRmL GKZUYQd4hmMORAyzxaUow+NVHQ3+WHU1d/9TQDKf3ojp/whdjrrkv2tXRBYtLjMGarFIDpGy M+muSzjWK6EmM273aYSH8LVQ1dZvJGSUMWwxB8aPojzSDJu+BYE+e+cCj0cyTeaAav143EOK 1hY6P1PM354uK4dtyFaWV/zXlTkgb1QahAab+uZgPAFDZXCoyr2JlPNM7z7ApW2XrYfiAoqP 5zcIRzE5eLLgykY0KgGywpMKbJEmMIwBM1gRzoD4odAgJGdof4T8npw5ZexrLn+xG1d964C1 bK6+7atE0zMPtWQ36eGCZ1M36q5yZLurHG7QwsUfkdDzml/Y1VFV6fQbhrsDDKaQ1kAocNjw BY05VjQwbaPrwt11Sa5SVfij0qA6DKhk9h0SOuqEb9bkf80KPKwdNNEMay8eM0t5qs9KcLca XF80GoTFBidgMqV+fdW3El05PIADTKUCQ9/W48GD52fn/8R9LcbrdRDSsVjCH5UGoTFBmbLR NY2kIKkAmwgrDopMiZ1SU1dsfXtMRWUZjs7NtPBKqEGAKIlFpvNJMLW5yCUZUjnWdjT2vEau WwNgEFRgi2B5Bk9Aj4+mJiyAtY8u6Pij0iA0NpMv32B8JBKoK43vpQMGYFFjWSTIugTPLGAs rHxJlWnK54KNRzJNBgXO3xn/ChzOFHvpV3WjfWmJzHX342Hu1mn4kY/8Km0yF4ZqOves5XHF PV8Hjks1dYefoaZuxRBcMoY2bFX45+iKV6oyi2x1xVM3DT5xaejy3mcYfF0sSG6bqt3yrU44 tlkpIMeAxbADd3TkmEXDZzjg1Jyg20Yg+avO2VvN16/043JQenWXf6X67ugz6DtSJDz1jmyT vOj2sCQs80T6TWTgCIghmGzmGAx5/5FQc1Rdh9OcRNJQql1XhQs2kNhUALUHvpYli7UiQeMy E1GEBiMWu7eLisx5pptfiHC7rUgKy1RpeVJREJN3zVgszJm8xH7H8KD/Mt8rsdt0QpYZ2wo8 mu2CU2CxGAE3BclFLT4MIsqV9RpUwTtW3zqBszHki3xtBZtYhJXyNmAKvEdbITorSa7YCnP5 jk9X526LbmPEl/jaCjhYht0mezv9PVO5sHe4sz97r6he+QPwrcpXB6XYyZ4HtmrcDNoJn01B r+VsKxDN+B1QdKZhLueUQFnNjr8gv+YXYPcPGPHvYx6t8vCrKm4j1Ov52gpCeFgaxD2azuS+ jZVtZhshcqxDfVgUkuGJFTwPUfKeiogHfKXjVVFAm4Bey9ZW8AGdg6dZcCbnihfLrcWGsnQd ySgSAxrZo2MLtesrwdkQ8Bqutri8tOJMGNcZxVFOM5ooLGhPQN4jfst0zdjZbJsxe/PqwGuF xkZo17C0FWQq+yjml6l5xaex1GJwj2IuC1PNvnUPtmM8SS3ypIi2O8GzCd4PcLUVgIpjqDq2 pQPG+jDiTNbxgEicCv2+6GIjdquN3wjkBxj5Qj1WR3i+Du/uUb7xbl0rZgcneeV9LxZPohWJ GOjTnKhQWJzillPG6bgxa2b7V6laIswJOR3u90OhQUgGRjpAy/7EMJiMhyBh355YRwEUy1XG 2LvrC7Lf3W8bl1dpK9BcKmKnvJFHMk0mjph+BRHo1ZFJkFJ9FEIWiR3J/yqrbO0IcRuagF0I w9zZ/cMpXeKPSpNpI2Bmvqi8OD9bNCCQ8BRzFFAGFM1gCp6E5V+XflIXcHzSaRCeIZuQMezM Gaa/ipPyIVWUSJXlgTJvfMKgBKMZhs2jERbLjmPbjIY7vcnUH5UGodGHqTBNAHcNh+gDJMqY dUYJlnNX5uBxJxOJTii4NfzxRKJBUOBTjs29cFbMm6prDmCbKhXJYw7DsJJPhjRw7a/ijYgP YDybDbVkNylWe7VpHVl/xxaSbfLCscdTwaben7deDVUtu4eZnp2vteZKYCrMTB+tss2arQ4C 5fJn7vq2el80GlyaNqFr3wO9sBeBww7WHJ7lxY48pja/PNNtLnEr4/NHpUFozKnCWfwmY2lE p+1Zo8JOyTkBzz4UMRlwMGziHLdo92aRTyfRICgMJjIMZ3WGhejaKcbjpUmlKMBURh0arm19 mXSCxiuhJl0OZACtkt1Xc8zYPUnbL4Vla8YwoTrOo5UEcwfIK6GmASqbnwE///rlk+abJ1xh 69iFmbaNQGF2tY3jZFf7otGktsnyJKB4qiXIpqkSsKenY+MgFk1ZKhkRPfG6hSp2CzWDcFI4 3qg0CE1KedE0T7IgY0rPrynxLpI21qvW4ygnfsSwbZRya0Hnj0qj7gaaFT9fvHLyxZev/jri ZUvVJa8/T3WJbhCVCfCjYqMoFo5h6e28tmOazTGW3beCMRhAhRenj/wqLMFeAdNTuCgKU4xt FU1nFhgK7RJLDQrHbFSmDATtHlQ4Qp9nguXIh7YiD4dXLDU0CQ2/JBTM9jVzQK4K9SMJbgWb whhGzmJ7Bsb2v2vrQojCv7Aa/Ofra+xQBXPObc7aNUlVwPkYkluBBmW/1MQ00BIe6g1uMLX6 bndpt9fmgWOt0hKOm5HcCiizIod9dC1CNtRnQ61rhdIBT8p1O/prGwqplvFiXtsJm3k4H0F2 K+gM2Hw9mdYBs4hRqQkmur4hYSMBJiNOb276Aopqrnp1S7QFUDcjvRVwKmwU7noIO1igj1vH 2DqJK5O21v6pVKASioVxdv7PtmszvQdg3YD+VuCZNR5t6wZTaEvbHfemhAMHNMG8TnkKJJpW BuwmOg+AuxEHW4GooiXRlrYxrmI56UNB4GyZN6Rj/oJcYwjMzDmmE9ck3SrlmPXwbsLAVgBK BQcVGeamOm9cbVRvRLyYTw0MCtJscCD4H4Ryw+chcJ0Z2Ao6s5Hrv1XqrLCPIs60To4Rvc/A hmtf+GD2XdAeTtA8jKwr/S3ZgcbIzxPd/btsczUEz1WVMQxrrRUHWRybvz6E50ZEt4JKnvAQ dtTAtqfVga9hJCYYOdTHd8woypdBWCfe7i6r4klVqSzAfAK57Wgb4ynqvYMrEoHhBdaaFvBc 0hErpaXME7arDqUTOgijL0JNhtymKWyfuKbBVKV5pEPxYjjEHcQcHi8yyYW7rL0hEyPS7eV0 W3eHqJtPQk0G+3XOOCS2YjRP0CHEvpEdqXR8EMQ85MZYs7YIVnjYAy+ma5sLPj7pNAgPSPMd p+AhxtiQIrPlLcG6+sdZqwKH+7/OAF1/5zME6JxUVW1c7BNsYgm4FdhPxB5jLwJAswTT7KUj 6Llhk0EqWaW26ws+QfnQ6c/D7g6JdOe1ETPVWNqVtyGdmTth7UdsBh+adWhPyj7DMdfGgpaT 9N3qWcIZEjqA8QxHDXsuCLLAGJVtwTc/rkv4Eiw6BoaunX3ct80ZmLZ5l8ezG7MptpBKZLMs 8pJMWysQdhlznS0NiqbPV8J1mtcUwOmaXNvWZknye7DXlC8YD21vcNCA9m2Cz27cM60Ni/dX WTi3synHpd62qPx/e9fWnDayhN/Pr5ji4WS3CrC5+JY9mzoYx3FcZYcyVFJbqX0Y0GDpIEvU SDIhv/5094wuXAyDIwtjNg+7NkZqTaunp6en+/sS0BtNKqjySjs4arJbbeuZMgAYfUA9Jqo7 VPEN0FaNTSCEgu0K1ZMm7ce7NGTcU1QgnPYncWUobLkqNxdHFR1IllmG89ChPlDp+w+aIAi3 fDs3Zr2FmDVygunQ6dPEzCkV72BXzaPYUQ+WNgVhvA9vUWrnNHfSGanITFfT7W4ctoBfDrvD SLLEOVO6nTbUcTlcYuBpgLqD48bFl86jNWpffPiKrxlcmXCHMbIpYs/Mr91l1o92EdWcMiA6 /AgE7f2JLEdTzWXO5uEPFpYD8rSlhtKyOzfkIBpTCVFm6VGtcZZKEKUJkvibYerOeECcof9A 1LxMFqObjXjJwfKBjcSGWWdr+ZT3tuGNQcyU4VCh/KdJsiNHMQUqZ+zc309xyzR7rqS7m42y PIa3eKOJntqrSvS0PHXKvKp8ajhLEoSwZhhGhrY+8njFbugp9zs/kRihu6nzHsUwAZshiBZx jcGCR01pQAdBO8mXQg5E0cFTT1QGt27uZEZ4MdKHCztC9sCndLi3cyNO4AS+4ZA4aSCw+UhU MJh2BSHi4lKbpANUKXSIWyIE9AzCXdwKZq2X+OjwP4iOlFp8xeVTgcyNj0KqzWDoDB0RJ7p2 cNCpCb9DtFUnCCmtQ5xINMqAuDtxppcZNpbAOGM6yh0cbmqomNYYZfY+mbqFpCAvWxWyg4PF oLfvOoFNR+qtlOc468PnVqQZa9/BMasJumphoqkNf+ve9DpUortYwLxLA8aiUWnp9kjkDq+f 1mtl/Vo5K8UcflJwa1pisBPCA/Q55ezguGdeJx+GqryYCiaS9UrRmdCSBVPgFQ/yGbu75f+K 3gE0qseMXU370rGQikX6tBFbuy9Yfdnb2L48b5PY01s62tHGNYcLB8hJxRFYdx8Lo2dLptb1 Ff+ygAIVkilQpQmumlvTZZuG0RfwnAi2Byu1jsTN6o4yTGO5iSlQOfolBSqlDbEbp1B0HMl7 xU+KTw1/lFR0N9YpAyJf4K4G2jfRTp5yikxH/XVLDQLIcmgrb8MTb0P7MzzZoAUEcUCQiEDZ O48rig2JQnIVVGRKyg+cGSAdeBLigYmffgaGyMKfqLhIWKaayUdCgSoh8psMF6N6nWYtkasv 3dtlrVE9QTByKSbcdVUjcEf6P0w88/pL8xhEzopcKnYThJXj0qbYJ02NfXK2AcLK5lKOnpJi 5TwJdWlrmdn+BLMQihglAUJRiVXEilPsTLPMoLDvwTMekxmbp5wCfZQCP40LFhC9ECFzdeFr f0oc9RHslAIN4DyO+sl+XzsnM+3kJqZI5cTkuRlQXccbuqpeicA/kwTuEkpZM83kJKNAtcS8 7uplPuBQsIdZUuUpNTL5/SgIPSyRjsEbPNhVeyJUdG9m1E45iilQOTHIMxn1wI8kp7hWl8Ok DRtg/yllS0rAGxiFB7kJ2dtA4hjTmGmdIYFCr33IVRftrSaZgsfyYM0LdB4Yjy974NgvOTqu iYbUdB7GIozUQjiRTqgqIc3Wj3wkbGHp0IxhRFZIGC6Kr45OcOnM69oXrOeDryqzCwQBPMeG Ps+oPyUvGc9Sy8KRev0FjtTh8ktw6Agxxj75HkRX14J7lXM+DvF4id0gwib8tczatoRPHO6x q8gJxQMvL0c8Ia5yBS3S5k7oruSnzOMp5qQUlypmbLkGzsE0XEQKUFqYYHIfFo5h5GLCCjub vHvMR8WTJzUzI00tTbJrmWXWEaMRZ13+6LtcrestRFJlX8ZjgTbpLX+s4rVnNFYTZe3zuvAN cfF9b1Yz5K2RngOcEHhwHrLbVrf1LmCfXOF57E5o3Nw2HqNJo3AoTzkFqucy8iiSpweFfbRD pYY6vWeprue53J4eQst6RKJpIwCx/KQUqJq2ojrUtU5ldssfdeyqvEY3gp2B47r4fKwFr9FB MI4EerlL3asm2slVUD4LaeNlFtIeHsggLzAm1n9rtVvd3u9oBv+D8ahkRVd4AUygti/HvtQ6 WLeIKlMx8pbPewBti90x3xJqEUmes5MZSyD3gzNsqa4+IUPK/IHxSj1tLCpeZUmUMluttY8w 323WRSzuwS6ezCcmM2VfEFNcbOHk/XWurieEAIlrm+rPvhNDiJjgLa/fTq2/dG+1Chd/b92e nfxN92lFEoLUXlWdFVTZrTPiiAFQZqUuNrYR8Eg7LdwsGe3achFQoEIy/zrSRw51auLTeaZL qvRSeTeusUfgibVFsZUoL4lKchKxHaUkUwmhjOA9zrhvWNIGkcSTvDKrnZ2dGIWzv3zzvZ6/ 7Vbl7Lhar/1tNBkXvr0dI2p/vOvBrMf/YdjtBL6cMng2eK3HlXqNatEw+3+ZZP+9LKeqoTX9 opTtqKaL1H1UJq6S3qUy2P04FHQogk++6Zwyv2EeA35tB8Inzz4QbpxucCK8uZj4RLh5+NJH wt/b52dNtQK3bRFMnMGozL6pVbhbZefCdZHaGGbKbLlAfLpk5ljykbGlOacXFpgan7vnt+/Z Yf2wdtxoHJ2AMVxzL+LgOGCqNDeeexvfeK/XMsWTgPehwiZQURUs5k4EmGXWVQTkrNmF3439 mSYLwD8aWWpeQra0cmJhHJjTefei/eWW1Q8P62V2KfqSTAl/3dRGN7jjXhvnze311SH5uBs/ GPlgED/L7A5sJ93GdOC3a38kMNmPPxMoRpVdIXeMRKg9IwPNU9B2jLR0hT2Ln5EwB8N12OSE PqzYYGS/WZIPw4ojwmHFdsYVpPOuHDZ+N9JMPhK2o5LrCNZ6mExmFBErL3wbs3AhD9x8mTzw 907ztFJr4HSyODr8M/D2HZWGZbcQCIN+wWw6tkRIrht+z3+ChDL76rtIZHeyyjJXS1ma5ZN+ FAo1YR1viE1107jj8+nHKvDNL22r+RwEEUSqp7AuIHhzrYG5ihr8eh2507WbkqW3XKLoTcS8 jTnwzJXo7rJ9eHKGxtYBLyhcHcL0JPeCBycIMFfS9r1Q+m7WM3Z7F6vNOV2CcpGwHUeLjXzw 6LOb3NPapm533W323QBrtSaGKNd84PcJRPgrGkgbIaNEEKNWH3zuMFtwjEmoSMn1J5VgLMwO cvOTsh1DRMpl7uImn3IuaFA4nExsDR7tcFO73PCu+26m9dM6Hj5cCnkfkQF1VE7iooqnrw4s P6VbEU6woOKzd08ox7D2hAJB+d+bWmkuQrZjpBdJhf4FPKnqOOvqvudk62s7A5uJByxpR1q6 rh9JMybWXAVtR0EtzcEXZ1Fxo9zusMZpOW4Zh8DlhtNGeePJ/Lybv8U07enG+dPjZzAjby7l 5CkpuSZpX6P3/CYCV0zZTZV9tCwjfP3lVxT4yF/Bo/6EyPRSIGWxy2Knq6qWjAqvDW9R4KCw tGV5DZ/JeNZfXeBQ6jVwY+xc+v4I5uOI3Vng3brsqFk5MhmLweUFDqaNkO0ulUF/uWKs2aw1 jEax6rp9jtY6tu+J9/CSjyvNRqNyfHxaN1HnissKfPiPD9xx37OJAMf333s5qHo84NV7/9Fk CGsvfhtmsZDwO3qBhF9rjETtzg/Wqioo8rYpgc6TVy6t1bsQwUA6mr3snxK9BILFQajotIYH IZL5SHiqL+dcSETAcBAwbSL6KsTCup4M9KNRCJ2nnMLVgyDKUsT9WrroS8HHILR4dlhU48/D dBBUiWyqn5wEFaggbAbmhBGDLKYuHwjd79VTmFwypukMXBwrMjmBKxFStT9MsYTORD05iilQ OQnYWkypkEEfGvgeciniS9QgPD/4IGQPgnsIDYK+qm+WdctPSoGqwddWZtxNARYVfQZzLMEJ NyVmlVHwdp7GqteklCZ6yUlEgUqZJxohRDfwi9wQMdnk+n1e7FrZqeEQJazCyHQXVKfRn7IG UZ7h9lzdC5yfnCLdFZiL7cMT4TxJQbezJKcxoui7YGFERq4qFwmmKvnXbCz7a2a6oOul6TIb xuJicPln6ajE9HMNaPdeSqNpiFpLH/7t9YPxHx89AhdTCa2gympHcXJLsahW1dfSNNbsA+hn RRabYD5d53w4alAqLNC3tBgBvBBA5H8OnDT7Bl9l8x+cnS1eyy1r5sqlSlE6fFILySNj3g4e uS8/UOxjhw8uLdqqDVD6VjRQzX9yOKDPa9VGo0rYKy5SN4cMu+11KJliSFA4CZq2pRj+WbLD cPz+4GAymVRDH56pikUmVV/eH9CvB/reB6UP+psrv4Vvgc0OGX7o+9YUP0Dx+jP9EY7pw/8B 8tazsDooAQA= --/NkBOFFp2J2Af1nK 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 --/NkBOFFp2J2Af1nK-- From tcpm-bounces@ietf.org Thu Dec 14 10:22:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GusPW-0007yx-CF; Thu, 14 Dec 2006 10:22:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GusPV-0007yq-Js for tcpm@ietf.org; Thu, 14 Dec 2006 10:22:13 -0500 Received: from web33309.mail.mud.yahoo.com ([68.142.206.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GusPT-0006Ny-13 for tcpm@ietf.org; Thu, 14 Dec 2006 10:22:13 -0500 Received: (qmail 22766 invoked by uid 60001); 14 Dec 2006 15:22:09 -0000 Message-ID: <20061214152209.22764.qmail@web33309.mail.mud.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=urFjxZrge3dEWEtxJ4cZGSsnPvUHwUGcGvyAvrxrtNWF3UqeLVyzXvpR6AfHaf2tBms0uopmdS6BaViP3TjCdtHQn/69yjJT3Sjm1hoTKKxjpfukadMZvmPZk1ToNuUK8/NPcEaTy5BBd+Art85CQ3RFVvkYql2zA2hcKAsJYeM=; X-YMail-OSG: WZCdadMVM1kTnaUOnLbcJnKVEPHjeSV4BS1kE4RXBzs_F8vyni1qQMxtAFrprKMXpg-- Received: from [69.236.72.190] by web33309.mail.mud.yahoo.com via HTTP; Thu, 14 Dec 2006 07:22:09 PST Date: Thu, 14 Dec 2006 07:22:09 -0800 (PST) From: Pyda Srisuresh Subject: Re: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and TCP's reaction to soft errors) To: tcpm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Pyda Srisuresh , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, I looked up the following e-mail from Adrian in the mail archives. As someone that used open source code and responsible for the development of security appliances, I would fully support and second Andre Opperman's view. Fernando did a great job of uncovering the problems in ICMP that have been nascent for years. Having the problems and their current solutions formally documented as RFCs is a boon to to the current and future developers. Having the two ICMP docs formally published as RFCs is also immensely valuable to the current and future IETF contributors. I am a co-author of two Behave WG documents - TCP-Behave and ICMP-behave. Both of the Behave drafts refer Fernando's ICMP docs. I support forwarding both documents as RFCs at the earliest. Thank you. regards, suresh ---------------------------------------------------------------------------- > > To: Fernando Gont > Subject: Re: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and > TCP's > reaction to soft errors) > From: Andre Oppermann > Date: Thu, 07 Dec 2006 17:02:34 +0100 > Cc: tcpm at ietf.org, tsv-dir at ietf.org > > -------------------------------------------------------------------------------- > Fernando Gont wrote: > Folks, > > I would like to state my opinion on the question asked by Mark (wrt what we > would do with the ICMP docs if we were to take Matts suggestion for working > on > ICMP): > > * Both of the drafts are aiming at Informational, thus just describing "what > is > implemented out there". No matter what we end up standardizing, that will not > change what is currently implemented out there. That's one of the reasons for > which I think that even if we got consensus to proceed as suggested by Matt, > both documents should still be moved forward on the Informational path. > From the point of view of an actual kernel and TCP/IP stack developer > I can only say that this documentation is invaluable for reference and > for interoperability issues. > > > In my opinion having this documented and preserved as an informational RFC > helps people new to TCP it to find it and to avoid the mistakes of the > past. A new tcp/ip developer or hacker can avoid countless hours of > debugging and re-inventing the wheel by just looking at the work already > done for them by Fernando and all the other participants to it. Not > formally documenting it would just let it slide into obscurity quickly > and in a year or two only us 'greybeards' will remember it while the next > generation repeats history again. That's just wasteful. > > > This is a perfect application of the "standing on the shoulders of giants" > meme. > > > -- > Andre (@FreeBSD.ORG) > > > * In the case of the ICMP attacks draft, one of the goals of the document is > to > discuss ICMP-based attacks (other than "proposing mitigations). And many have > argued that it is really needed (e.g., it is not clear to everybody how TCP > MD5, IPsec, etc, interact with ICMP and TCP... and that's one of the things > the > draft tries to clarify). > > * There are already a few RFCs, around ten internet drafts (including one by > the IAB), and a few papers referencing it, and it is worth noting that while > we > have two documents on TCP-based spoofing attacks (antispoof and tcpsecure), > if > we were to drop the ICMP attacks draft we would end up having no doc > describing > ICMP attacks against TCP (which, ironically, are simpler than their TCP-based > counter-part). > > * Another thing with the ICMP attacks draft is that it describes quite a few > mitigations that have been widely implemented, and not just the TCP SEQ check > and that of dropping ICMP SQ. Therefore, even if we were to pull the ICMP SQ > and the TCP SEQ check stuff from the document, there's still more stuff in > the > document that makes the draft worth publishing. > > * I agree that the ICMP attacks draft needs more work. In the last few > revisions I have been addressing lots of technical comments posted by many of > you on the list. That's why I have not yet completely tackled those parts of > the draft that are still "too prescriptive". This is going to be the goal of > the next revision which, in the event anybody sends text (it's a wg doc!), > will > probably converge even sooner than expected. > > * In the case of the ICMP soft errors draft, we have had discussions for the > last two years, and we didn't get consensus to standardize the "abort the > connection reset upon receipt of an ICMP soft error". But there are many > implementations that already perform some alternative reaction to ICMP error > messages received during the connection-establishment phase. I think we had > already got consensus to document it. And the draft is very close (if not > already) for WGLC (we bounced the doc a few times with Mark, and I will be > able > to publish a revision anytime soon). > > * It is worth noting that we were recently talking about how to encourage > participation of open source projects in the IETF. The ICMP attacks draft has > benefited from the feedback of all major open source OSes, along the two > years > it has been around. While we certainly should not make a decision based > exclusively on this point, I'm not sure all those guys would be happy to > provide feedback on future drafts if they realize that the time they spent > during two years contributing to an IETF doc basically ended up in nothing. > > > Kindest regards, > > > -- > Fernando Gont > e-mail: fernando at gont.com.ar || fgont at acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Dec 15 10:19:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvEqQ-0000NO-82; Fri, 15 Dec 2006 10:19:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvEqO-0000NC-Ko for tcpm@ietf.org; Fri, 15 Dec 2006 10:19:28 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvEqK-0001QZ-Gp for tcpm@ietf.org; Fri, 15 Dec 2006 10:19:28 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id kBFFJNrj010358 for ; Fri, 15 Dec 2006 07:19:23 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 7C5525B9191 for ; Fri, 15 Dec 2006 10:21:53 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id CC888152159 for ; Fri, 15 Dec 2006 10:18:52 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Touch of Grey MIME-Version: 1.0 Date: Fri, 15 Dec 2006 10:18:52 -0500 Message-Id: <20061215151852.CC888152159@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Subject: [tcpm] Mark Allman: [Tsvwg] new version of early retransmit 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="===============0817792758==" Errors-To: tcpm-bounces@ietf.org --===============0817792758== Content-Type: multipart/signed; boundary="===_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --===_bOundary Content-Type: multipart/mixed; boundary="==_bOundary" --==_bOundary Content-Type: text/plain Content-Disposition: inline Folks- I sent the attached message to tsvwg a couple days back. This is the revival of an old document that was in tsvwg at about the time tcpm was forming. There is some wondering on the tsvwg list now about whether this revival ought to happen over here. In any case, comments welcome... wherever they come from. allman --==_bOundary Content-Type: message/rfc822 Content-Disposition: attachment; filename=5246 Content-Description: forwarded message Return-Path: mallman@icir.org Delivery-Date: Thu Dec 14 09:08:37 2006 Return-Path: X-Original-To: mallman@localhost Delivered-To: mallman@localhost.icir.org Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 669B85AE042 for ; Thu, 14 Dec 2006 09:08:37 -0500 (EST) Received: from mailhost.icsi.berkeley.edu [192.150.186.11] by guns.icir.org with IMAP (fetchmail-6.3.4) for (single-drop); Thu, 14 Dec 2006 09:08:37 -0500 (EST) Received: from pork.ICSI.Berkeley.EDU (pork [192.150.186.19]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id kBEE5jbO015538 for ; Thu, 14 Dec 2006 06:05:45 -0800 (PST) Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id kBEE5iaf008298 for ; Thu, 14 Dec 2006 06:05:44 -0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurCs-0004np-DM; Thu, 14 Dec 2006 09:05:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurCs-0004nk-2H for tsvwg@ietf.org; Thu, 14 Dec 2006 09:05:06 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GurCp-0007T8-Bn for tsvwg@ietf.org; Thu, 14 Dec 2006 09:05:05 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id kBEE52WH008265 for ; Thu, 14 Dec 2006 06:05:02 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 2B8E75AE02F for ; Thu, 14 Dec 2006 09:07:34 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id ED01B1517DA for ; Thu, 14 Dec 2006 09:04:33 -0500 (EST) To: tsvwg@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Touch of Grey MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 14 Dec 2006 09:04:33 -0500 Message-Id: <20061214140433.ED01B1517DA@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Tsvwg] new version of early retransmit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org X-ClamAV: OK X-SpamProbe: SKIPPED X-mallman-sequence: icir tsvwg --=_bOundary Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable We recently re-submitted the early retransmit I-D that we pushed along a while back: =20 Title : Early Retransmit for TCP and SCTP Author(s) : M. Allman, et al. Filename : draft-allman-tcp-early-rexmt-04.txt Pages : 10 Date : 2006-11-26 http://www.ietf.org/internet-drafts/draft-allman-tcp-early-rexmt-04= .txt We stopped pushing this I-D because some of our analysis of network traces seemed to indicate that ER was sort of a crapshoot, failing as much as succeeding. However, given that we never went beyond sort of a preliminary assessment and did not publish the results (/ let them stand against peer review) we no longer think we should stop the ER draft because of these results. Further, the results were from on particular network and it would seem useful to gain a broad understanding of how ER works in a variety of environments. My recollection is that once upon a time the TSVWG had some consensus to take on ER as a work item with the intention of publishing it as an experimental RFC. I am not asking the WG that question right now. But, we may ask that question soon, if the chairs are amenable. Right now we just want to alert folks that this draft is out and solicit comments From=20the WG. Thanks! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFgVnxWyrrWs4yIs4RAotAAJ91lIprfAyfdpM01mNtFs0mz2WghQCcDZSw 0yfEbk3WN32dSg/t0uUfC9w= =F/ye -----END PGP SIGNATURE----- --=_bOundary-- --==_bOundary-- --===_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFgrzcWyrrWs4yIs4RArIMAJ9xGmK8tVkjpN9zDFF9EcGVVwDejgCeLubG E2mPC2vo40Y6sPYhIGRcelc= =KpFf -----END PGP SIGNATURE----- --===_bOundary-- --===============0817792758== 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 --===============0817792758==-- From tcpm-bounces@ietf.org Fri Dec 15 15:02:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvJF9-0005Ro-1q; Fri, 15 Dec 2006 15:01:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvJF8-0005Rf-1O for tcpm@ietf.org; Fri, 15 Dec 2006 15:01:18 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvJF6-0000Xz-Kh for tcpm@ietf.org; Fri, 15 Dec 2006 15:01:18 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id kBFK10LQ025074; Fri, 15 Dec 2006 12:01:01 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 6E6335BB9E1; Fri, 15 Dec 2006 15:03:30 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id EC7E3152828; Fri, 15 Dec 2006 15:00:29 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Touch of Grey MIME-Version: 1.0 Date: Fri, 15 Dec 2006 15:00:29 -0500 Message-Id: <20061215200029.EC7E3152828@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Ethan Blanton , Ted Faber , Josh Blanton Subject: [tcpm] spurious timeout reaction 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="===============0716673445==" Errors-To: tcpm-bounces@ietf.org --===============0716673445== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- Recently we posted an update to our i-d on reacting to spurious timeouts. It is: Title : Using Spurious Retransmissions to Adapt the Retransmission Timeout Author(s) : M. Allman, et al. Filename : draft-allman-rto-backoff-04.txt Pages : 8 Date : 2006-12-12 http://www.ietf.org/internet-drafts/draft-allman-rto-backoff-04.txt The changes were pretty minor and editorial in nature. We think the document is in decent shape and that it might make a good standards track mechanism for reacting to spurious timeouts. The basic idea is that we say a TCP MAY make the RTO estimate more conservative in the face of spurious timeouts with the hopes of avoiding future timeouts. In particular, we believe that since RFC2988 explicitly allows a TCP to be more conservative than the estimator given in that RFC that this reaction is already allowed and a stack using it would be considered compliant. The WG discussed this sometime back and we believe we have made all the suggested updates. Do folks have further thoughts? Clearly my co-chair hat is off on this one. Maybe Ted could advise us of a procedure to determine what to do next on this? Thanks! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFgv7dWyrrWs4yIs4RAt22AKCHuwyXpjS3HYpJm2BoFPNPg4EiOwCcD+ni ZTzfdoS8VbwiFZTEkfr6Is8= =aHV9 -----END PGP SIGNATURE----- --=_bOundary-- --===============0716673445== 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 --===============0716673445==--