From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Sat Mar 1 20:40:28 2003 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22136 for ; Sat, 1 Mar 2003 20:40:27 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h221Y456013827 for ; Sat, 1 Mar 2003 17:34:04 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h221Y3gP009194 for ; Sat, 1 Mar 2003 17:34:04 -0800 (PST) Received: from thebe.your-site.com (ns5.your-site.com [140.186.45.30] (may be forged)) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id h221YKI2000021 for ; Sat, 1 Mar 2003 17:34:21 -0800 (PST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 2842E244D85; Sat, 1 Mar 2003 20:31:23 -0500 (EST) Date: Sat, 1 Mar 2003 19:33:02 -0600 From: Caitlin Bestler Subject: RE: Matching addresses in INIT and INIT ACK To: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit On 2/25/03, Ivan.Arias-Rodriguez@nokia.com wrote: >> >> I want to ask, is it wrong to match only the address >> received in IP header ? > >Yes, it is... If you don't do that, you could end up >having open associations that having the same address/port >as source, also have the same address/port at the >destination. > >Imagine that you have an open association with >AddrA/PortA... Then I send you an INIT from AddrB/PortA >which also includes AddrA inside a parameter... If you go >on with the association establishment, at the end you will >have that packets coming from AddrA/PortA go either to the >first or the second association. Depending on how much >care you have put on this, it could be that an attacker is >able to abort associations established by others... > >Or another example with the INIT ACK. Imagine your user >tells you to establish an association with AddrA/PortA and >also with AddrB/PortA, roughly at the same time... But >then, inside the first INIT ACK you receive, you realize >that those two addresses belong to the same peer... When >you receive the second INIT ACK you shouldn't send back >the COOKIE ECHO but understand that you are basically >trying to establish the same association twice... > I'm in full agreement with the above, but there's a step in the solution that is still missing. The scenario, as I understand it, deals with a client that attempts to create two associations with the same remote endpoint without realizing that it is the same endpoint: Host A Host B == Host C INIT from A:1000 to B:1000----------------> INIT form A:1000 to C:1000----------------> <--------------------------------------INIT-ACK to A:1000 from B|C:1000 <--------------------------------------INIT-ACK to A:1000 from B|C:1000 Am I correct that the point of the clarification is that despite the different Verfication Tags, the two Init-ACKs SHOULD be applied to the same TCB. (Actually I'm unclear as to why that is not a MUST). What's missing is that the eclipsed TCB needs to be terminated. The resources should be released promptly, but more importantly it SHOULD NOT retransmit. Correct? Caitlin Bestler http://asomi.com/CaitlinBestler/ From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Sat Mar 1 22:18:51 2003 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23669 for ; Sat, 1 Mar 2003 22:18:50 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h223ERHK007937 for ; Sat, 1 Mar 2003 19:14:27 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h223EjOm011098 for ; Sat, 1 Mar 2003 19:14:45 -0800 (PST) Received: from gw.openss7.com (IDENT:CcVUBCUnrjivVbdKFzckrcn5uhyo732r@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h223CwtH017459 for ; Sat, 1 Mar 2003 19:12:59 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:+JKQmyJw1CTIQViGEF6GjkPvUel9DE0c@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2239aD04320; Sat, 1 Mar 2003 20:09:36 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2239Za09117; Sat, 1 Mar 2003 20:09:35 -0700 Date: Sat, 1 Mar 2003 20:09:35 -0700 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030301200935.A9071@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Sat, Mar 01, 2003 at 07:33:02PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Caitlin, On Sat, 01 Mar 2003, Caitlin Bestler wrote: > On 2/25/03, Ivan.Arias-Rodriguez@nokia.com wrote: > > > >> > >> I want to ask, is it wrong to match only the address > >> received in IP header ? > > > >Yes, it is... If you don't do that, you could end up > >having open associations that having the same address/port > >as source, also have the same address/port at the > >destination. > > > >Imagine that you have an open association with > >AddrA/PortA... Then I send you an INIT from AddrB/PortA > >which also includes AddrA inside a parameter... If you go > >on with the association establishment, at the end you will > >have that packets coming from AddrA/PortA go either to the > >first or the second association. Depending on how much > >care you have put on this, it could be that an attacker is > >able to abort associations established by others... > > > >Or another example with the INIT ACK. Imagine your user > >tells you to establish an association with AddrA/PortA and > >also with AddrB/PortA, roughly at the same time... But > >then, inside the first INIT ACK you receive, you realize > >that those two addresses belong to the same peer... When > >you receive the second INIT ACK you shouldn't send back > >the COOKIE ECHO but understand that you are basically > >trying to establish the same association twice... > > > > > I'm in full agreement with the above, but there's a step in > the solution that is still missing. > > The scenario, as I understand it, deals with a client that > attempts to create two associations with the same remote > endpoint without realizing that it is the same endpoint: > > Host A Host B == Host C > > INIT from A:1000 to B:1000----------------> > INIT form A:1000 to C:1000----------------> > <--------------------------------------INIT-ACK to A:1000 > from B|C:1000 > <--------------------------------------INIT-ACK to A:1000 > from B|C:1000 > > > Am I correct that the point of the clarification is that > despite the different Verfication Tags, the two Init-ACKs > SHOULD be applied to the same TCB. (Actually I'm unclear > as to why that is not a MUST). > > What's missing is that the eclipsed TCB needs to be > terminated. The resources should be released promptly, > but more importantly it SHOULD NOT retransmit. Correct? No such thing. The example as you describe (without other addresses in the INIT) are two valid associations. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Sun Mar 2 12:43:42 2003 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15203 for ; Sun, 2 Mar 2003 12:43:41 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h22HaW6N020913; Sun, 2 Mar 2003 09:36:32 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADZ32029; Sun, 2 Mar 2003 09:36:30 -0800 (PST) Message-ID: <3E62411E.4090401@cisco.com> Date: Sun, 02 Mar 2003 11:36:30 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Caitlin Bestler CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030301200935.A9071@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Caitlin, > >On Sat, 01 Mar 2003, Caitlin Bestler wrote: > > > >>On 2/25/03, Ivan.Arias-Rodriguez@nokia.com wrote: >> >> >> >> >>>>I want to ask, is it wrong to match only the address >>>>received in IP header ? >>>> >>>> >>>Yes, it is... If you don't do that, you could end up >>>having open associations that having the same address/port >>>as source, also have the same address/port at the >>>destination. >>> >>>Imagine that you have an open association with >>>AddrA/PortA... Then I send you an INIT from AddrB/PortA >>>which also includes AddrA inside a parameter... If you go >>>on with the association establishment, at the end you will >>>have that packets coming from AddrA/PortA go either to the >>>first or the second association. Depending on how much >>>care you have put on this, it could be that an attacker is >>>able to abort associations established by others... >>> >>>Or another example with the INIT ACK. Imagine your user >>>tells you to establish an association with AddrA/PortA and >>>also with AddrB/PortA, roughly at the same time... But >>>then, inside the first INIT ACK you receive, you realize >>>that those two addresses belong to the same peer... When >>>you receive the second INIT ACK you shouldn't send back >>>the COOKIE ECHO but understand that you are basically >>>trying to establish the same association twice... >>> >>> >>> >>I'm in full agreement with the above, but there's a step in >>the solution that is still missing. >> >>The scenario, as I understand it, deals with a client that >>attempts to create two associations with the same remote >>endpoint without realizing that it is the same endpoint: >> >>Host A Host B == Host C >> >>INIT from A:1000 to B:1000----------------> >>INIT form A:1000 to C:1000----------------> >><--------------------------------------INIT-ACK to A:1000 >> from B|C:1000 >><--------------------------------------INIT-ACK to A:1000 >> from B|C:1000 >> >> >>Am I correct that the point of the clarification is that >>despite the different Verfication Tags, the two Init-ACKs >>SHOULD be applied to the same TCB. (Actually I'm unclear >>as to why that is not a MUST). >> >>What's missing is that the eclipsed TCB needs to be >>terminated. The resources should be released promptly, >>but more importantly it SHOULD NOT retransmit. Correct? >> >> Yes, Caitlin you are completely correct... you are NOT allowed to have two associations between the same set of endpoints aka. Host-A Host B IP-A:1000 <-------------------------------------------> IP-B, IP-C :1000 Cann only have ONE association between the two endpoints. And the above scenario where Host-A sends INIT's to IP-B and IP-C port 1000 would attempt to cause that situation. I think Brian answers below like he does for the same reason he answered earlier in this thread on how an association would not come up (in my and Ivan's example) .. which is he has a very very specialized stack for IUA/SS7 world. It is REQUIRED to pre-know all the addresses on each side. Now a stack vendor COULD require this but it really makes the use of its stack very limited.. In a general purpose stack, say for HTTP or peer to peer communication within the internet, one would NOT want to impose this requirement... it may make sense for the SS7/signalling world.. but not for a general SCTP stack.. I took a look at Brian's code.. his hashing to tags scheme will work due to his requirement i.e. that all of the addresses of both sides are pre-known.. Very limited IMO and not something I would want in my stack... But if it meets your requirments thats fine... R >No such thing. The example as you describe (without other >addresses in the INIT) are two valid associations. > >--brian > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Sun Mar 2 17:50:22 2003 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19881 for ; Sun, 2 Mar 2003 17:50:21 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h22MjcHK012412 for ; Sun, 2 Mar 2003 14:45:39 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h22Mjv98019784 for ; Sun, 2 Mar 2003 14:45:58 -0800 (PST) Received: from gw.openss7.com (IDENT:g5owPb28YYvxQ0B4IdzlGpgmTi/MnDou@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h22Mjp9t004964 for ; Sun, 2 Mar 2003 14:45:51 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:Rvd1i8HVJY3KW53CAHE6TXTupinLz8CL@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h22MeWD01436; Sun, 2 Mar 2003 15:40:32 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h22MeVN31310; Sun, 2 Mar 2003 15:40:31 -0700 Date: Sun, 2 Mar 2003 15:40:31 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Caitlin Bestler , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030302154031.A30876@openss7.org> Reply-To: bidulock@openss7.org References: <20030301200935.A9071@openss7.org> <3E62411E.4090401@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E62411E.4090401@cisco.com>; from rrs@cisco.com on Sun, Mar 02, 2003 at 11:36:30AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Sun, 02 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >Caitlin, > > > >On Sat, 01 Mar 2003, Caitlin Bestler wrote: > > > > > > > >>On 2/25/03, Ivan.Arias-Rodriguez@nokia.com wrote: > >> > >> > >> > >> > >>>>I want to ask, is it wrong to match only the address > >>>>received in IP header ? > >>>> > >>>> > >>>Yes, it is... If you don't do that, you could end up > >>>having open associations that having the same address/port > >>>as source, also have the same address/port at the > >>>destination. > >>> > >>>Imagine that you have an open association with > >>>AddrA/PortA... Then I send you an INIT from AddrB/PortA > >>>which also includes AddrA inside a parameter... If you go > >>>on with the association establishment, at the end you will > >>>have that packets coming from AddrA/PortA go either to the > >>>first or the second association. Depending on how much > >>>care you have put on this, it could be that an attacker is > >>>able to abort associations established by others... > >>> > >>>Or another example with the INIT ACK. Imagine your user > >>>tells you to establish an association with AddrA/PortA and > >>>also with AddrB/PortA, roughly at the same time... But > >>>then, inside the first INIT ACK you receive, you realize > >>>that those two addresses belong to the same peer... When > >>>you receive the second INIT ACK you shouldn't send back > >>>the COOKIE ECHO but understand that you are basically > >>>trying to establish the same association twice... > >>> > >>> > >>> > >>I'm in full agreement with the above, but there's a step in > >>the solution that is still missing. > >> > >>The scenario, as I understand it, deals with a client that > >>attempts to create two associations with the same remote > >>endpoint without realizing that it is the same endpoint: > >> > >>Host A Host B == Host C > >> > >>INIT from A:1000 to B:1000----------------> > >>INIT form A:1000 to C:1000----------------> > >><--------------------------------------INIT-ACK to A:1000 > >> from B|C:1000 > >><--------------------------------------INIT-ACK to A:1000 > >> from B|C:1000 > >> > >> No, I meant that there is nothing the matter with: Host A Host B == Host C INIT from A:1000 to B:1000----------------> INIT form A:1000 to C:1000----------------> <--------------------------------------INIT-ACK to A:1000 from B|C:1000 <--------------------------------------INIT-ACK to A:1000 from B|C:1000 Forming two associations as: A:1000 <--------------------------------------> B:1000 and A:1000 <--------------------------------------> C:1000 Regardless of whether B and C are on the same endpoint. Further, if the intention is to form an assocation: A:1000 <----------------------------------> B:1000 C:1000 There is no need to peer in the INIT in this case. It is not until the COOKIE-ECHO is sent that any assocation is fully formed (no TCB exists). So, for example, if the first INIT is for A:1000-->B:1000 and the initiator does not get a response fast enough, it should be free to send A:1000->C:1000 and get a valid INIT-ACK. The host receiving the INIT cannot refuse the second INIT, because to do so would be to maintain state from the first INIT. Only once it receives a second COOKIE-ECHO for an existing TCB is it necessary to be careful to establish only one association. I did not say that it was unnecessary to examine the addresses in a COOKIE-ECHO. It is just not necessary in the INIT or INIT-ACK. For proper populate of tie-tags in the cookie, it is necessary to determine if there is an existing TCB when an INIT is received. However, there can only be one socket bound to the local port number for the destination address (be it B or C) so there is still no need to look in the address list of the INIT to find the TCB to populate tie-tags. This is true in general, and is not application-specific. So, it is not necessary to look in the address list of the INIT as a general rule, so don't try to tell me I "SHOULD". The INIT-ACK case can be handled by VT, so don't try to tell me I "SHOULD" there either. Thank you. --brian > >>Am I correct that the point of the clarification is that > >>despite the different Verfication Tags, the two Init-ACKs > >>SHOULD be applied to the same TCB. (Actually I'm unclear > >>as to why that is not a MUST). > >> > >>What's missing is that the eclipsed TCB needs to be > >>terminated. The resources should be released promptly, > >>but more importantly it SHOULD NOT retransmit. Correct? > >> > >> > Yes, Caitlin you are completely correct... you are NOT > allowed to have two associations between the same set > of endpoints aka. > > Host-A > Host B > IP-A:1000 <-------------------------------------------> IP-B, > IP-C :1000 > > > Cann only have ONE association between the two endpoints. > And the above scenario where Host-A sends INIT's to IP-B and IP-C > port 1000 would attempt to cause that situation. > > I think Brian answers below like he does for the same reason he > answered earlier in this thread on how an association would not > come up (in my and Ivan's example) .. which is he has a very very > specialized stack for IUA/SS7 world. It is REQUIRED to pre-know > all the addresses on each side. Now a stack vendor COULD require > this but it really makes the use of its stack very limited.. In a general > purpose stack, say for HTTP or peer to peer communication within > the internet, one would NOT want to impose this requirement... it > may make sense for the SS7/signalling world.. but not for a general > SCTP stack.. > > I took a look at Brian's code.. his hashing to tags scheme will > work due to his requirement i.e. that all of the addresses of both > sides are pre-known.. Very limited IMO and not something I > would want in my stack... But if it meets your requirments thats > fine... > > R > > >No such thing. The example as you describe (without other > >addresses in the INIT) are two valid associations. > > > >--brian > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Mar 3 03:21:58 2003 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11698 for ; Mon, 3 Mar 2003 03:21:57 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h238DC56028219 for ; Mon, 3 Mar 2003 00:13:12 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h238DBXv023271 for ; Mon, 3 Mar 2003 00:13:11 -0800 (PST) Received: from india.mercurykr.com (ptil-59-162-ind.primus-india.net [203.196.162.59] (may be forged)) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h238D09t007340 for ; Mon, 3 Mar 2003 00:13:02 -0800 (PST) Received: from vijay (ptil-29-162-ind.primus-india.net [203.196.162.29] (may be forged)) by india.mercurykr.com (8.11.2/8.11.2) with SMTP id h23DCmO05900 for ; Mon, 3 Mar 2003 18:43:10 +0530 MIME-Version: 1.0 Message-Id: <3E630C29.000003.10233@vijay.india.mercurykr.com> Date: Mon, 3 Mar 2003 13:32:49 +0530 (India Standard Time) Content-Type: Text/Plain X-Mailer: IncrediMail 2001 (1500245) From: "Vijay Kumar Choudhary" X-Priority: 3 X-FID: FLAVOR00-NONE-0000-0000-000000000000 To: Subject: SCTP Fragmentation!!!! Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA11698 Hi All, In the SCTP Imp Guide Version 7, it is written that " If an implementation that supports fragmentation makes available to its upper layer a mechanism to turn off fragmentation it may do so. However in so doing, it MUST react just like an implementation that does NOT support fragmentation i.e. it MUST reject sends that exceed the current P-MTU. " How the upper layer can specify whether it wants fragmentation or not ? (Using which primitive) Regards, Vijay From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Mar 3 03:50:40 2003 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12084 for ; Mon, 3 Mar 2003 03:50:39 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h238ixP7018552 for ; Mon, 3 Mar 2003 00:44:59 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h238jDYC027396 for ; Mon, 3 Mar 2003 00:45:13 -0800 (PST) Received: from 161.44.11.97 (channel-print.demon.co.uk [194.222.164.86]) by proxy1.cisco.com (8.12.2/8.11.2) with SMTP id h238ir9t020313 for ; Mon, 3 Mar 2003 00:45:03 -0800 (PST) Received: from [101.129.173.198] by 161.44.11.97 with ESMTP id QQQQEY; Mon, 03 Mar 03 00:27:07 +0400 Received: from [250.26.127.102] by 101.129.173.198 with ESMTP id EEYTHK; Mon, 03 Mar 03 00:22:07 +0400 From: "Loyd Huggins" Message-ID: To: sctp-impl@external.cisco.com Date: Mon, 03 Mar 03 00:22:07 GMT X-Priority: 3 X-MSMail-Priority: Normal Subject: drink beam X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=ZUKMCNYJIVSXPJWJMO This is a multi-part message in MIME format. --ZUKMCNYJIVSXPJWJMO Content-Type: text/html Content-Transfer-Encoding: 7Bit
Hey dude, how are you? this site will not cost you a cent
F*r*ee  s*e*x on the web

Pictures  movies  games  chat

and most importantly:

Its all for  f*r*ee.

 
To stop receiving ads, please enter the site and click un*subscribe
--ZUKMCNYJIVSXPJWJMO-- From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Mar 3 05:57:14 2003 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16556 for ; Mon, 3 Mar 2003 05:57:13 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h239nUHK021106 for ; Mon, 3 Mar 2003 01:49:30 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h239nn7g028304 for ; Mon, 3 Mar 2003 01:49:49 -0800 (PST) Received: from 192.168.1.100 (CPE002078d4b49a-CM000039e56262.cpe.net.cable.rogers.com [24.192.124.54]) by proxy1.cisco.com (8.12.2/8.11.2) with SMTP id h239na9t017132 for ; Mon, 3 Mar 2003 01:49:38 -0800 (PST) Message-Id: <200303030949.h239na9t017132@proxy1.cisco.com> From: "need a jjob?" To: Subject: Get paid for filling out surveys!!! Sender: "need a jjob?" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="= Multipart Boundary 0303030449" Date: Mon, 3 Mar 2003 04:49:37 -0500 Reply-To: "need a jjob?" This is a multipart MIME message. --= Multipart Boundary 0303030449 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Get Paid For Your Opinions! Earn up to $150 For an Hour of Work! Find out how your ideas and insight can work for you! CLICK HERE NOW! Start Earning Today! CLICK HERE! --= Multipart Boundary 0303030449 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit

Get Paid
For Your Opinions!

Earn up to $150
For an Hour of Work!

Find out how your ideas
and insight can work for you!
 

CLICK HERE NOW!
Start Earning Today!
CLICK HERE!

--= Multipart Boundary 0303030449-- From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Mar 3 07:19:56 2003 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20298 for ; Mon, 3 Mar 2003 07:19:55 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h23CCEP7020091; Mon, 3 Mar 2003 04:12:14 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADZ67788; Mon, 3 Mar 2003 04:12:27 -0800 (PST) Message-ID: <3E6346AB.70607@cisco.com> Date: Mon, 03 Mar 2003 06:12:27 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Caitlin Bestler , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030301200935.A9071@openss7.org> <3E62411E.4090401@cisco.com> <20030302154031.A30876@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Sun, 02 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian F. G. Bidulock wrote: >> >> >> >>>Caitlin, >>> >>>On Sat, 01 Mar 2003, Caitlin Bestler wrote: >>> >>> >>> >>> >>> >>>>On 2/25/03, Ivan.Arias-Rodriguez@nokia.com wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>I want to ask, is it wrong to match only the address >>>>>>received in IP header ? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Yes, it is... If you don't do that, you could end up >>>>>having open associations that having the same address/port >>>>>as source, also have the same address/port at the >>>>>destination. >>>>> >>>>>Imagine that you have an open association with >>>>>AddrA/PortA... Then I send you an INIT from AddrB/PortA >>>>>which also includes AddrA inside a parameter... If you go >>>>>on with the association establishment, at the end you will >>>>>have that packets coming from AddrA/PortA go either to the >>>>>first or the second association. Depending on how much >>>>>care you have put on this, it could be that an attacker is >>>>>able to abort associations established by others... >>>>> >>>>>Or another example with the INIT ACK. Imagine your user >>>>>tells you to establish an association with AddrA/PortA and >>>>>also with AddrB/PortA, roughly at the same time... But >>>>>then, inside the first INIT ACK you receive, you realize >>>>>that those two addresses belong to the same peer... When >>>>>you receive the second INIT ACK you shouldn't send back >>>>>the COOKIE ECHO but understand that you are basically >>>>>trying to establish the same association twice... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>I'm in full agreement with the above, but there's a step in >>>>the solution that is still missing. >>>> >>>>The scenario, as I understand it, deals with a client that >>>>attempts to create two associations with the same remote >>>>endpoint without realizing that it is the same endpoint: >>>> >>>>Host A Host B == Host C >>>> >>>>INIT from A:1000 to B:1000----------------> >>>>INIT form A:1000 to C:1000----------------> >>>><--------------------------------------INIT-ACK to A:1000 >>>> from B|C:1000 >>>><--------------------------------------INIT-ACK to A:1000 >>>> from B|C:1000 >>>> >>>> >>>> >>>> > >No, I meant that there is nothing the matter with: > >Host A Host B == Host C > >INIT from A:1000 to B:1000----------------> >INIT form A:1000 to C:1000----------------> ><--------------------------------------INIT-ACK to A:1000 > from B|C:1000 ><--------------------------------------INIT-ACK to A:1000 > from B|C:1000 > >Forming two associations as: > >A:1000 <--------------------------------------> B:1000 > >and > >A:1000 <--------------------------------------> C:1000 > >Regardless of whether B and C are on the same endpoint. > >Further, if the intention is to form an assocation: > >A:1000 <----------------------------------> B:1000 > C:1000 > >There is no need to peer in the INIT in this case. It is not >until the COOKIE-ECHO is sent that any assocation is fully >formed (no TCB exists). > >So, for example, if the first INIT is for A:1000-->B:1000 and >the initiator does not get a response fast enough, it should be >free to send A:1000->C:1000 and get a valid INIT-ACK. > >The host receiving the INIT cannot refuse the second INIT, >because to do so would be to maintain state from the first INIT. > >Only once it receives a second COOKIE-ECHO for an existing TCB >is it necessary to be careful to establish only one association. >I did not say that it was unnecessary to examine the addresses >in a COOKIE-ECHO. It is just not necessary in the INIT or >INIT-ACK. > I believe Caitlin was talking about the case where the INIT-ACK had two addresses in it (aka B:1000, C:1000).. The case above, two seperate endpoints, is correct as well ... different case though (at least its how I interpreted what Caitlin was getting at.. Caitlin?) > >For proper populate of tie-tags in the cookie, it is necessary >to determine if there is an existing TCB when an INIT is >received. However, there can only be one socket bound to the >local port number for the destination address (be it B or C) so >there is still no need to look in the address list of the INIT >to find the TCB to populate tie-tags. > >This is true in general, and is not application-specific. > >So, it is not necessary to look in the address list of the >INIT as a general rule, so don't try to tell me I "SHOULD". > >The INIT-ACK case can be handled by VT, so don't try to tell >me I "SHOULD" there either. > > If you don't look in the INIT for addresses your VT method only works if: A) you can assure that you hand out unique VT's and B) you KNOW all the addresses that the peer can give you apriori Both of the above our true in your implementation.. My point is, for a general implementation that WILL NOT be able to assrue above, you need to look in the INIT-ACK... R >Thank you. > >--brian > > > >>>>Am I correct that the point of the clarification is that >>>>despite the different Verfication Tags, the two Init-ACKs >>>>SHOULD be applied to the same TCB. (Actually I'm unclear >>>>as to why that is not a MUST). >>>> >>>>What's missing is that the eclipsed TCB needs to be >>>>terminated. The resources should be released promptly, >>>>but more importantly it SHOULD NOT retransmit. Correct? >>>> >>>> >>>> >>>> >>Yes, Caitlin you are completely correct... you are NOT >>allowed to have two associations between the same set >>of endpoints aka. >> >>Host-A >> Host B >>IP-A:1000 <-------------------------------------------> IP-B, >>IP-C :1000 >> >> >>Cann only have ONE association between the two endpoints. >>And the above scenario where Host-A sends INIT's to IP-B and IP-C >>port 1000 would attempt to cause that situation. >> >>I think Brian answers below like he does for the same reason he >>answered earlier in this thread on how an association would not >>come up (in my and Ivan's example) .. which is he has a very very >>specialized stack for IUA/SS7 world. It is REQUIRED to pre-know >>all the addresses on each side. Now a stack vendor COULD require >>this but it really makes the use of its stack very limited.. In a general >>purpose stack, say for HTTP or peer to peer communication within >>the internet, one would NOT want to impose this requirement... it >>may make sense for the SS7/signalling world.. but not for a general >>SCTP stack.. >> >>I took a look at Brian's code.. his hashing to tags scheme will >>work due to his requirement i.e. that all of the addresses of both >>sides are pre-known.. Very limited IMO and not something I >>would want in my stack... But if it meets your requirments thats >>fine... >> >>R >> >> >> >>>No such thing. The example as you describe (without other >>>addresses in the INIT) are two valid associations. >>> >>>--brian >>> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Mar 3 07:30:25 2003 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20921 for ; Mon, 3 Mar 2003 07:30:24 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h23CLa6N015310; Mon, 3 Mar 2003 04:21:36 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADZ68077; Mon, 3 Mar 2003 04:21:35 -0800 (PST) Message-ID: <3E6348CF.8030607@cisco.com> Date: Mon, 03 Mar 2003 06:21:35 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Kumar Choudhary CC: sctp-impl@external.cisco.com Subject: Re: SCTP Fragmentation!!!! References: <3E630C29.000003.10233@vijay.india.mercurykr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Kumar Choudhary wrote: >Hi All, > In the SCTP Imp Guide Version 7, it is written that > " If an implementation that supports fragmentation makes > available to its upper layer a mechanism to turn off fragmentation > it may do so. However in so doing, it MUST react just like an > implementation that does NOT support fragmentation i.e. it MUST > reject sends that exceed the current P-MTU. " > >How the upper layer can specify whether it wants fragmentation or not ? >(Using which primitive) > >Regards, >Vijay > > > Vijay: In the sockets-api there is a socket option called: SCTP_DISABLE_FRAGMENTS Its in section 7.1.12 of the new sctpsocket-06 spec.. (probably the same section in any previous version as well.. it has been there for a while). It reads: " 7.1.12 Enable/Disable message fragmentation (SCTP_DISABLE_FRAGMENTS) This option is a on/off flag. If enabled no SCTP message fragmentation will be performed. Instead if a message being sent exceeds the current PMTU size, the message will NOT be sent and instead a error will be indicated to the user. " R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Mar 3 08:56:18 2003 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25744 for ; Mon, 3 Mar 2003 08:56:17 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h23Dmp6N024354 for ; Mon, 3 Mar 2003 05:48:51 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h23DmouG023671 for ; Mon, 3 Mar 2003 05:48:51 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h23DmZx6019584 for ; Mon, 3 Mar 2003 05:48:37 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h23DX1Q21664 for ; Mon, 3 Mar 2003 15:33:01 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Mar 2003 15:29:45 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 15:29:44 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 15:29:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Mon, 3 Mar 2003 15:29:43 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLhfjZAKdfH2NKGR/y1A6/ogeAlCwACeAEA From: To: , Cc: , X-OriginalArrivalTime: 03 Mar 2003 13:29:44.0639 (UTC) FILETIME=[F41194F0:01C2E188] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA25744 snip... > >So, it is not necessary to look in the address list of the > >INIT as a general rule, so don't try to tell me I "SHOULD". > > > >The INIT-ACK case can be handled by VT, so don't try to tell > >me I "SHOULD" there either. > > > > > If you don't look in the INIT for addresses your VT method only > works if: > > A) you can assure that you hand out unique VT's > and > B) you KNOW all the addresses that the peer can give you apriori > > Both of the above our true in your implementation.. > > My point is, for a general implementation that WILL NOT be able > to assrue above, you need to look in the INIT-ACK... And there is another point that Brian never answered: Does the general restart/establishment collision procedure (section 5.2 of RFC 2960) work not checking the addresses inside the INIT? Because, I don't see how are you going to populate the Tie Tags or not, if you don't know if the INIT comes from an already established (but crashed) association (or one that it is being formed, i.e., INIT collision)... But I guess there might be another way of doing it, which I fail to see... :-/ BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Mar 3 11:16:31 2003 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01393 for ; Mon, 3 Mar 2003 11:16:24 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h23GBk6N022426 for ; Mon, 3 Mar 2003 08:11:46 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h23GBjRk009661 for ; Mon, 3 Mar 2003 08:11:45 -0800 (PST) Received: from gw.openss7.com (IDENT:JT+XU2x/vlqcsyGfNslZ+v47S5PpY+GQ@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id h23GBsMp010737 for ; Mon, 3 Mar 2003 08:11:56 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:xnWdxmq+OfhiFlCk47bjwTZ8I8Ox0ObN@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23G6dD17427; Mon, 3 Mar 2003 09:06:39 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23G6dk13314; Mon, 3 Mar 2003 09:06:39 -0700 Date: Mon, 3 Mar 2003 09:06:38 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Caitlin Bestler , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303090638.A13272@openss7.org> Reply-To: bidulock@openss7.org References: <20030301200935.A9071@openss7.org> <3E62411E.4090401@cisco.com> <20030302154031.A30876@openss7.org> <3E6346AB.70607@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E6346AB.70607@cisco.com>; from rrs@cisco.com on Mon, Mar 03, 2003 at 06:12:27AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >Randall, > > > >On Sun, 02 Mar 2003, Randall Stewart (cisco) wrote: > > > > > > > >>Brian F. G. Bidulock wrote: > >> > >> > >> > >>>Caitlin, > >>> > >>>On Sat, 01 Mar 2003, Caitlin Bestler wrote: > >>> > >>> > >>> > >>> > >>> > >>>>On 2/25/03, Ivan.Arias-Rodriguez@nokia.com wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>>I want to ask, is it wrong to match only the address > >>>>>>received in IP header ? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>Yes, it is... If you don't do that, you could end up > >>>>>having open associations that having the same address/port > >>>>>as source, also have the same address/port at the > >>>>>destination. > >>>>> > >>>>>Imagine that you have an open association with > >>>>>AddrA/PortA... Then I send you an INIT from AddrB/PortA > >>>>>which also includes AddrA inside a parameter... If you go > >>>>>on with the association establishment, at the end you will > >>>>>have that packets coming from AddrA/PortA go either to the > >>>>>first or the second association. Depending on how much > >>>>>care you have put on this, it could be that an attacker is > >>>>>able to abort associations established by others... > >>>>> > >>>>>Or another example with the INIT ACK. Imagine your user > >>>>>tells you to establish an association with AddrA/PortA and > >>>>>also with AddrB/PortA, roughly at the same time... But > >>>>>then, inside the first INIT ACK you receive, you realize > >>>>>that those two addresses belong to the same peer... When > >>>>>you receive the second INIT ACK you shouldn't send back > >>>>>the COOKIE ECHO but understand that you are basically > >>>>>trying to establish the same association twice... > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>I'm in full agreement with the above, but there's a step in > >>>>the solution that is still missing. > >>>> > >>>>The scenario, as I understand it, deals with a client that > >>>>attempts to create two associations with the same remote > >>>>endpoint without realizing that it is the same endpoint: > >>>> > >>>>Host A Host B == Host C > >>>> > >>>>INIT from A:1000 to B:1000----------------> > >>>>INIT form A:1000 to C:1000----------------> > >>>><--------------------------------------INIT-ACK to A:1000 > >>>> from B|C:1000 > >>>><--------------------------------------INIT-ACK to A:1000 > >>>> from B|C:1000 > >>>> > >>>> > >>>> > >>>> > > > >No, I meant that there is nothing the matter with: > > > >Host A Host B == Host C > > > >INIT from A:1000 to B:1000----------------> > >INIT form A:1000 to C:1000----------------> > ><--------------------------------------INIT-ACK to A:1000 > > from B|C:1000 > ><--------------------------------------INIT-ACK to A:1000 > > from B|C:1000 > > > >Forming two associations as: > > > >A:1000 <--------------------------------------> B:1000 > > > >and > > > >A:1000 <--------------------------------------> C:1000 > > > >Regardless of whether B and C are on the same endpoint. > > > >Further, if the intention is to form an assocation: > > > >A:1000 <----------------------------------> B:1000 > > C:1000 > > > >There is no need to peer in the INIT in this case. It is not > >until the COOKIE-ECHO is sent that any assocation is fully > >formed (no TCB exists). > > > >So, for example, if the first INIT is for A:1000-->B:1000 and > >the initiator does not get a response fast enough, it should be > >free to send A:1000->C:1000 and get a valid INIT-ACK. > > > >The host receiving the INIT cannot refuse the second INIT, > >because to do so would be to maintain state from the first INIT. > > > >Only once it receives a second COOKIE-ECHO for an existing TCB > >is it necessary to be careful to establish only one association. > >I did not say that it was unnecessary to examine the addresses > >in a COOKIE-ECHO. It is just not necessary in the INIT or > >INIT-ACK. > > > I believe Caitlin was talking about the case where the INIT-ACK had > two addresses in it (aka B:1000, C:1000).. The case above, two > seperate endpoints, is correct as well ... different case though > (at least its how I interpreted what Caitlin was getting at.. Caitlin?) Read above, I'm talking of the B + C case. > > > > >For proper populate of tie-tags in the cookie, it is necessary > >to determine if there is an existing TCB when an INIT is > >received. However, there can only be one socket bound to the > >local port number for the destination address (be it B or C) so > >there is still no need to look in the address list of the INIT > >to find the TCB to populate tie-tags. > > > >This is true in general, and is not application-specific. > > > >So, it is not necessary to look in the address list of the > >INIT as a general rule, so don't try to tell me I "SHOULD". > > > >The INIT-ACK case can be handled by VT, so don't try to tell > >me I "SHOULD" there either. > > > > > If you don't look in the INIT for addresses your VT method only > works if: > > A) you can assure that you hand out unique VT's > and > B) you KNOW all the addresses that the peer can give you apriori > > Both of the above our true in your implementation.. > > My point is, for a general implementation that WILL NOT be able > to assrue above, you need to look in the INIT-ACK... You didn't read above. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Mar 3 11:27:10 2003 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01785 for ; Mon, 3 Mar 2003 11:27:09 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h23GIIP7020974 for ; Mon, 3 Mar 2003 08:18:18 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h23GIVIj001874 for ; Mon, 3 Mar 2003 08:18:32 -0800 (PST) Received: from gw.openss7.com (IDENT:n40g5fyhl+nltUJn8xhlDTE9XespJwnh@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h23GGNuX022467 for ; Mon, 3 Mar 2003 08:16:27 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:gpjIS7B9S43fd1Bb/RRaRdwg4ngJEgjB@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23GBoD17488; Mon, 3 Mar 2003 09:11:50 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23GBoA13394; Mon, 3 Mar 2003 09:11:50 -0700 Date: Mon, 3 Mar 2003 09:11:50 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: rrs@cisco.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303091149.B13272@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Mon, Mar 03, 2003 at 03:29:43PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Mon, 03 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > snip... > > > >So, it is not necessary to look in the address list of the > > >INIT as a general rule, so don't try to tell me I "SHOULD". > > > > > >The INIT-ACK case can be handled by VT, so don't try to tell > > >me I "SHOULD" there either. > > > > > > > > If you don't look in the INIT for addresses your VT method only > > works if: > > > > A) you can assure that you hand out unique VT's > > and > > B) you KNOW all the addresses that the peer can give you apriori > > > > Both of the above our true in your implementation.. > > > > My point is, for a general implementation that WILL NOT be able > > to assrue above, you need to look in the INIT-ACK... > > And there is another point that Brian never answered: > > Does the general restart/establishment collision procedure (section > 5.2 of RFC 2960) work not checking the addresses inside the INIT? Yes it does, because the destination address and port numbers of the INIT are sufficient to find an existing TCB. > > Because, I don't see how are you going to populate the Tie Tags or > not, if you don't know if the INIT comes from an already established > (but crashed) association (or one that it is being formed, i.e., INIT > collision)... You didn't read what I wrote in the last note. The destination address and port numbers are sufficient to find the existing TCB from which the tie tags are populated. It is not necessary to dig the address list. > > But I guess there might be another way of doing it, which I fail to see... :-/ Digging the address list is not necessary to find an existing TCB. All that is necessary is the destination address and port pair from the INIT. --brian > > BR Iván Arias Rodríguez -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Mar 3 11:52:45 2003 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02746 for ; Mon, 3 Mar 2003 11:52:44 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h23Gf256012540 for ; Mon, 3 Mar 2003 08:41:12 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h23GePtX000394 for ; Mon, 3 Mar 2003 08:40:25 -0800 (PST) Received: from thebe.your-site.com (ns5.your-site.com [140.186.45.30] (may be forged)) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h23GcouX012254 for ; Mon, 3 Mar 2003 08:38:56 -0800 (PST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id CAAE624526D; Mon, 3 Mar 2003 11:37:19 -0500 (EST) Date: Mon, 3 Mar 2003 10:39:03 -0600 From: Caitlin Bestler Subject: Re: Matching addresses in INIT and INIT ACK To: bidulock@openss7.org, sctp-impl@external.cisco.com X-Priority: 3 In-Reply-To: <20030303091149.B13272@openss7.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Brian, Is your point that there is no need to check the INIT-ACK when it arrives because the other end can check the INIT-ACK inside the State Cookie in the COOKIE-ECHO? If so, what is the benefit of deferring the check? The extra costs, delay and a redundant COOKIE-ECHO, are admittedly minor. But why tolerate any excess network traffic that could have been prevented by simply using the data already available? Caitlin Bestler http://asomi.com/CaitlinBestler/ From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Mar 3 12:14:34 2003 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03488 for ; Mon, 3 Mar 2003 12:14:32 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h23H6fHK020559 for ; Mon, 3 Mar 2003 09:06:41 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h23H70eE005470 for ; Mon, 3 Mar 2003 09:07:00 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h23H6Wx6008858 for ; Mon, 3 Mar 2003 09:06:39 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h23GonY09954 for ; Mon, 3 Mar 2003 18:50:49 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Mar 2003 18:47:33 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 18:47:33 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 18:47:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Mon, 3 Mar 2003 18:47:32 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLhoKuOS0ngv9qtSiexLnkzYKpR0QAABj8g From: To: Cc: , , X-OriginalArrivalTime: 03 Mar 2003 16:47:32.0854 (UTC) FILETIME=[96137960:01C2E1A4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA03488 Brian, > Ivan.Arias-Rodriguez, > > On Mon, 03 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > snip... > > > > > >So, it is not necessary to look in the address list of the > > > >INIT as a general rule, so don't try to tell me I "SHOULD". > > > > > > > >The INIT-ACK case can be handled by VT, so don't try to tell > > > >me I "SHOULD" there either. > > > > > > > > > > > If you don't look in the INIT for addresses your VT method only > > > works if: > > > > > > A) you can assure that you hand out unique VT's > > > and > > > B) you KNOW all the addresses that the peer can give you apriori > > > > > > Both of the above our true in your implementation.. > > > > > > My point is, for a general implementation that WILL NOT be able > > > to assrue above, you need to look in the INIT-ACK... > > > > And there is another point that Brian never answered: > > > > Does the general restart/establishment collision > procedure (section > > 5.2 of RFC 2960) work not checking the addresses inside > the INIT? > > Yes it does, because the destination address and port numbers > of the INIT > are sufficient to find an existing TCB. Aha... they are sufficient... yes... of course... I am Host A and I want to establish the following association with Host Z: (AddrA; PortA):(AddrZ; PortZ). I send and INIT from (AddrA; PortA) to (AddrZ; PortZ). Host Z happens to be multihomed. You DON'T know which are the addresses of Host Z. Knowing this is outside SCTP, and if you happen to know all the addresses of Host Z (in fact, of all the existing hosts you could ever have an association with) BEFORE you ever got an INIT or INIT ACK from Host Z, that's because you are in a SPECIAL situation. Period. Host Z happens to have another address, AddrZ'. We are in an INIT collision scenario, and Host Z sends you an INIT from (AddrZ'; PortZ) to (AddrA; PortA). That INIT includes AddrZ inside a parameter. Now, Brian, can you tell me how in Earth would you recognize that INIT from Host Z as coming from the same host you want to connect with? Of course, I mean WITHOUT taking a look to the parameters of the INIT chunk... > > Because, I don't see how are you going to populate the > Tie Tags or > > not, if you don't know if the INIT comes from an > already established > > (but crashed) association (or one that it is being > formed, i.e., INIT > > collision)... > > You didn't read what I wrote in the last note. The > destination address and > port numbers are sufficient to find the existing TCB from > which the tie tags > are populated. It is not necessary to dig the address list. I cannot ask you this in a clearer way than written above. Could you please answer me to THIS question? BR Iván Arias Rodríguez > > But I guess there might be another way of doing it, > which I fail to see... :-/ > > Digging the address list is not necessary to find an existing > TCB. All that > is necessary is the destination address and port pair from the INIT. > > --brian > > > > > BR Iván Arias Rodríguez > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Mar 3 12:41:06 2003 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04372 for ; Mon, 3 Mar 2003 12:41:04 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h23HYN6N027783 for ; Mon, 3 Mar 2003 09:34:23 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h23HXkA5009782 for ; Mon, 3 Mar 2003 09:33:46 -0800 (PST) Received: from gw.openss7.com (IDENT:Evx16VCh4yj1613FppIvV1iqiANxRm7A@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h23HXsx6019911 for ; Mon, 3 Mar 2003 09:33:59 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:vcdMBfzsUQxManfw76lnyc0DLj/WO+Fq@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23HTSD18768; Mon, 3 Mar 2003 10:29:28 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23HTSD15885; Mon, 3 Mar 2003 10:29:28 -0700 Date: Mon, 3 Mar 2003 10:29:28 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: rrs@cisco.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303102928.A15597@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Mon, Mar 03, 2003 at 06:47:32PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Mon, 03 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > > Ivan.Arias-Rodriguez, > > > > On Mon, 03 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > > > snip... > > > > > > > >So, it is not necessary to look in the address list of the > > > > >INIT as a general rule, so don't try to tell me I "SHOULD". > > > > > > > > > >The INIT-ACK case can be handled by VT, so don't try to tell > > > > >me I "SHOULD" there either. > > > > > > > > > > > > > > If you don't look in the INIT for addresses your VT method only > > > > works if: > > > > > > > > A) you can assure that you hand out unique VT's > > > > and > > > > B) you KNOW all the addresses that the peer can give you apriori > > > > > > > > Both of the above our true in your implementation.. > > > > > > > > My point is, for a general implementation that WILL NOT be able > > > > to assrue above, you need to look in the INIT-ACK... > > > > > > And there is another point that Brian never answered: > > > > > > Does the general restart/establishment collision > > procedure (section > > > 5.2 of RFC 2960) work not checking the addresses inside > > the INIT? > > > > Yes it does, because the destination address and port numbers > > of the INIT > > are sufficient to find an existing TCB. > > Aha... they are sufficient... yes... of course... > > I am Host A and I want to establish the following association with > Host Z: (AddrA; PortA):(AddrZ; PortZ). > > I send and INIT from (AddrA; PortA) to (AddrZ; PortZ). > > Host Z happens to be multihomed. You DON'T know which are the > addresses of Host Z. Knowing this is outside SCTP, and if you happen > to know all the addresses of Host Z (in fact, of all the existing > hosts you could ever have an association with) BEFORE you ever got an > INIT or INIT ACK from Host Z, that's because you are in a SPECIAL > situation. Period. > > Host Z happens to have another address, AddrZ'. We are in an INIT > collision scenario, and Host Z sends you an INIT from (AddrZ'; PortZ) > to (AddrA; PortA). That INIT includes AddrZ inside a parameter. > > Now, Brian, can you tell me how in Earth would you recognize that INIT > from Host Z as coming from the same host you want to connect with? > > Of course, I mean WITHOUT taking a look to the parameters of the INIT > chunk... Collision cannot be detected until COOKIE-ECHO is received (RFC 2960 5.2.4 (B)). One does not have to peer into the address list of the INIT or INIT-ACK to detect collision. > > > Because, I don't see how are you going to populate the > > Tie Tags or > > > not, if you don't know if the INIT comes from an > > already established > > > (but crashed) association (or one that it is being > > formed, i.e., INIT > > > collision)... > > > > You didn't read what I wrote in the last note. The > > destination address and > > port numbers are sufficient to find the existing TCB from > > which the tie tags > > are populated. It is not necessary to dig the address list. > > I cannot ask you this in a clearer way than written above. Could you > please answer me to THIS question? What has your question to do with lookin in address lists of INIT and INIT-ACK? --brian > > BR Iván Arias Rodríguez > > > > But I guess there might be another way of doing it, > > which I fail to see... :-/ > > > > Digging the address list is not necessary to find an existing > > TCB. All that > > is necessary is the destination address and port pair from the INIT. > > > > --brian > > > > > > > > BR Iván Arias Rodríguez > > > > -- > > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > > ¦ Therefore all progress depends on the ¦ > > ¦ unreasonable man. -- George Bernard Shaw ¦ > > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Mar 3 12:45:44 2003 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04627 for ; Mon, 3 Mar 2003 12:45:43 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h23HchP7015225 for ; Mon, 3 Mar 2003 09:38:43 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h23Hcvx4000739 for ; Mon, 3 Mar 2003 09:38:57 -0800 (PST) Received: from gw.openss7.com (IDENT:nYezY8N3uu+w6lZ0khp1yif8g1XK200k@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id h23HcqMp011422 for ; Mon, 3 Mar 2003 09:38:57 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:I83xpQv9qCtvXJ++TXBllItQ19pz9FwW@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23HXGD18859; Mon, 3 Mar 2003 10:33:16 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23HXGc15966; Mon, 3 Mar 2003 10:33:16 -0700 Date: Mon, 3 Mar 2003 10:33:16 -0700 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303103316.B15597@openss7.org> Reply-To: bidulock@openss7.org References: <20030303091149.B13272@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Mon, Mar 03, 2003 at 10:39:03AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Caitlin, What excess traffic? None of the actions in RFC 2960 section 5.2.4 can be detected until COOKIE-ECHO is received. Attempting to determine these things from the INIT or INIT-ACK is attempting to fortell the future. The result of trying to fortell the future is valid init attempts being refused. --brian On Mon, 03 Mar 2003, Caitlin Bestler wrote: > Brian, > > Is your point that there is no need to check the INIT-ACK > when it arrives because the other end can check the INIT-ACK > inside the State Cookie in the COOKIE-ECHO? > > If so, what is the benefit of deferring the check? The extra > costs, delay and a redundant COOKIE-ECHO, are admittedly > minor. But why tolerate any excess network traffic that > could have been prevented by simply using the data already > available? > > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Mar 3 13:24:12 2003 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06326 for ; Mon, 3 Mar 2003 13:24:10 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h23I9Z56024992 for ; Mon, 3 Mar 2003 10:09:35 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h23I9ZEk008073 for ; Mon, 3 Mar 2003 10:09:35 -0800 (PST) Received: from thebe.your-site.com (ns5.your-site.com [140.186.45.30] (may be forged)) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h23I7buX000560 for ; Mon, 3 Mar 2003 10:07:38 -0800 (PST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id BE6752452F4; Mon, 3 Mar 2003 13:06:01 -0500 (EST) Date: Mon, 3 Mar 2003 12:07:45 -0600 From: Caitlin Bestler Subject: Re: Matching addresses in INIT and INIT ACK To: bidulock@openss7.org Cc: sctp-impl@external.cisco.com X-Priority: 3 In-Reply-To: <20030303103316.B15597@openss7.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit On 3/3/03, Brian F. G. Bidulock wrote: >Caitlin, > >What excess traffic? None of the actions in RFC 2960 >section 5.2.4 can be detected until COOKIE-ECHO is >received. Attempting to determine these things from the >INIT or INIT-ACK is attempting to fortell the future. The >result of trying to fortell the future is valid init >attempts being refused. > >--brian > > >On Mon, 03 Mar 2003, Caitlin Bestler wrote: > >> Brian, >> >> Is your point that there is no need to check the >> INIT-ACK when it arrives because the other end can check >> the INIT-ACK inside the State Cookie in the COOKIE-ECHO? >> >> If so, what is the benefit of deferring the check? The >> extra costs, delay and a redundant COOKIE-ECHO, are >> admittedly minor. But why tolerate any excess network >> traffic that could have been prevented by simply using >> the data already available? >> >> >> Caitlin Bestler >> http://asomi.com/CaitlinBestler/ > INIT from A:1000 to B:1000 ------------------------------> INIT form A:1000 to C:1000 ------------------------------> <-------------------------------------INIT-ACK TO A:1000 from [b,c]:1000 <-------------------------------------INIT-ACK TO A:1000 from [b,c]:1000 If A properly expands the scope of the first association's TCB upon receipt to cover both b and c, then the second INIT-ACK will be recognized as redundant. Only a single COOKIE-ECHO will be sent. If A shirks the responsibility of examining the address list within the INIT-ACK, and instead relies upon B/C to do the check when it/they process their COOKIE-ECHOEs then there will be *two* COOKIE-ECHOs sent. The second COOKIE-ECHO is an excess message that should be prevented. Further, A SHOULD also realize that the TCB it created for "A:1000 - C:1000" has been eclipsed by "A:1000 - [B,C]:1000" That the "A:1000 - C:1000" TCB should be removed. More importantly it should be prevent from retransmitting its INIT message. If no action is taken that would be the logical result as that it never received an INIT-ACK response. There is no fortune-telling going on here. The INIT-ACK clearly informs A that [B,C]:1000 is a single endpoint. At the time that B/C generates each INIT-ACK it does not have enough information to know that A is incorrectly attempting to create two associations with identical endpoints. After all, *no* records of prior INIT-ACKs are supposed to be kept on the passive side. Doing so creates a weakness for a denial-of-service attack. A (the active side) has the first opportunity to identify and correct the problem. If A wants to leave excess TCBs and indexes dangling around that its business, but generating excess traffic (when there was sufficient information to prevent those messages) is a legitimate network issue. Caitlin Bestler http://asomi.com/CaitlinBestler/ From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Mar 3 13:28:34 2003 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06485 for ; Mon, 3 Mar 2003 13:28:33 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h23ILeP9021517; Mon, 3 Mar 2003 10:21:42 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEA11448; Mon, 3 Mar 2003 10:21:52 -0800 (PST) Message-ID: <3E639D40.8050005@cisco.com> Date: Mon, 03 Mar 2003 12:21:52 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Caitlin Bestler , sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030303091149.B13272@openss7.org> <20030303103316.B15597@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Caitlin, > >What excess traffic? None of the actions in RFC 2960 section 5.2.4 >can be detected until COOKIE-ECHO is received. Attempting to determine >these things from the INIT or INIT-ACK is attempting to fortell the >future. The result of trying to fortell the future is valid init >attempts being refused. > > There is nothing special or magical about a cookie. It is NOT fortelling the future to look in a INIT (or INIT-ACK for that matter )that has come in to determine if you can setup an association, if the association is valid you will gain the proper tie-tag information.. if it is invalid you can dump it up front and save the bandwidth of generating a cookie (both for the network as well as your md5 or sha-1 cpu cycles) and dump the packet early... something you will be doing under the scenarios which Ivan as outlined when you have a general purpose stack where you have no pre-knowledge of the addresses your peer may have... R > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Mar 3 13:28:38 2003 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06502 for ; Mon, 3 Mar 2003 13:28:36 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h23IKfPH019951; Mon, 3 Mar 2003 10:23:35 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEA09337; Mon, 3 Mar 2003 10:16:19 -0800 (PST) Message-ID: <3E639BF3.6010403@cisco.com> Date: Mon, 03 Mar 2003 12:16:19 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030303102928.A15597@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: > > >> Aha... they are sufficient... yes... of course... >> >> I am Host A and I want to establish the following association with >> Host Z: (AddrA; PortA):(AddrZ; PortZ). >> >> I send and INIT from (AddrA; PortA) to (AddrZ; PortZ). >> >> Host Z happens to be multihomed. You DON'T know which are the >> addresses of Host Z. Knowing this is outside SCTP, and if you happen >> to know all the addresses of Host Z (in fact, of all the existing >> hosts you could ever have an association with) BEFORE you ever got an >> INIT or INIT ACK from Host Z, that's because you are in a SPECIAL >> situation. Period. >> >> Host Z happens to have another address, AddrZ'. We are in an INIT >> collision scenario, and Host Z sends you an INIT from (AddrZ'; PortZ) >> to (AddrA; PortA). That INIT includes AddrZ inside a parameter. >> >> Now, Brian, can you tell me how in Earth would you recognize that INIT >> from Host Z as coming from the same host you want to connect with? >> >> Of course, I mean WITHOUT taking a look to the parameters of the INIT >> chunk... >> >> > >Collision cannot be detected until COOKIE-ECHO is received >(RFC 2960 5.2.4 (B)). One does not have to peer into the >address list of the INIT or INIT-ACK to detect collision. > > Collision detection is not what Ivan is talking about.. you MUST find the old association (if there is one) so you can populate the tie-tags so you CAN do a collision detection as discussed in that section. You cannot do the detection without the tie tags being properly populated, and you cannot populate the tie-tags without this address lookup.. unless of course you have a special implementation (as you do) that has pre-knowledge on all of the addresses the peer has. Please think beyond your specialized implementation where you have NO KNOWLEDGE of any of the peer addresses... Then maybe you can answer Ivan's question above, which you seem to be ignoring.. > > >>>> Because, I don't see how are you going to populate the >>>> >>>> >>>Tie Tags or >>> >>> >>>> not, if you don't know if the INIT comes from an >>>> >>>> >>>already established >>> >>> >>>> (but crashed) association (or one that it is being >>>> >>>> >>>formed, i.e., INIT >>> >>> >>>> collision)... >>>> >>>> >>>You didn't read what I wrote in the last note. The >>>destination address and >>>port numbers are sufficient to find the existing TCB from >>>which the tie tags >>>are populated. It is not necessary to dig the address list. >>> >>> >> I cannot ask you this in a clearer way than written above. Could you >> please answer me to THIS question? >> >> > >What has your question to do with lookin in address lists of INIT >and INIT-ACK? > > See above... R > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Mar 3 13:44:37 2003 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07037 for ; Mon, 3 Mar 2003 13:44:37 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h23Ib7P7014207 for ; Mon, 3 Mar 2003 10:37:07 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h23IbLqJ029121 for ; Mon, 3 Mar 2003 10:37:21 -0800 (PST) Received: from gw.openss7.com (IDENT:GUF1OfZo0Li1j1fJr6gla4Zmj/WoVOtl@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id h23IbQMp002669 for ; Mon, 3 Mar 2003 10:37:29 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:kLPnNeRqBwXOQsRFKva3r3/x66kiBb4h@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23IWED19823; Mon, 3 Mar 2003 11:32:14 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23IWEo17354; Mon, 3 Mar 2003 11:32:14 -0700 Date: Mon, 3 Mar 2003 11:32:13 -0700 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303113213.A16782@openss7.org> Reply-To: bidulock@openss7.org References: <20030303103316.B15597@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Mon, Mar 03, 2003 at 12:07:45PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Caitlin, On Mon, 03 Mar 2003, Caitlin Bestler wrote: > On 3/3/03, Brian F. G. Bidulock wrote: > > >Caitlin, > > > >What excess traffic? None of the actions in RFC 2960 > >section 5.2.4 can be detected until COOKIE-ECHO is > >received. Attempting to determine these things from the > >INIT or INIT-ACK is attempting to fortell the future. The > >result of trying to fortell the future is valid init > >attempts being refused. > > > >--brian > > > > > >On Mon, 03 Mar 2003, Caitlin Bestler wrote: > > > >> Brian, > >> > >> Is your point that there is no need to check the > >> INIT-ACK when it arrives because the other end can check > >> the INIT-ACK inside the State Cookie in the COOKIE-ECHO? > >> > >> If so, what is the benefit of deferring the check? The > >> extra costs, delay and a redundant COOKIE-ECHO, are > >> admittedly minor. But why tolerate any excess network > >> traffic that could have been prevented by simply using > >> the data already available? > >> > >> > >> Caitlin Bestler > >> http://asomi.com/CaitlinBestler/ > > > > INIT from A:1000 to B:1000 ------------------------------> > INIT form A:1000 to C:1000 ------------------------------> > <-------------------------------------INIT-ACK TO A:1000 > from [b,c]:1000 > <-------------------------------------INIT-ACK TO A:1000 > from [b,c]:1000 Oh, you are back to this example. There is no need to peer into the address lists to do what is required here. The information from the IP and SCTP headers of the INIT-ACK is sufficient. If these are two INITs for the same connection, then VT (and port pair and destination address) in the INIT-ACK is sufficient to identify the association and deem one redundant. No need to examine address lists. Only one COOKIE-ECHO will be sent. If these are INITs for two different connections then the TCB of the first INIT-ACK is expanded. The TCB is again identified by VT (and port pair and destination address). There is no need to peer into the source address list. The second INIT-ACK to arrive has a destination address which corresponds to the TCB of the first. VT, destination address, source address and port pair is sufficient to identify that the second INIT-ACK belongs to the first TCB. Only one COOKIE-ECHO will be sent. Again: it is not necessary to look in the address list of the INIT or INIT-ACK. The IP and SCTP header has all of the information necessary to identify an existing TCB. Do you see yet? --brian > > If A properly expands the scope of the first association's > TCB upon receipt to cover both b and c, then the second > INIT-ACK will be recognized as redundant. Only a single > COOKIE-ECHO will be sent. > > If A shirks the responsibility of examining the address > list within the INIT-ACK, and instead relies upon B/C to > do the check when it/they process their COOKIE-ECHOEs > then there will be *two* COOKIE-ECHOs sent. The second > COOKIE-ECHO is an excess message that should be prevented. > > Further, A SHOULD also realize that the TCB it created for > "A:1000 - C:1000" has been eclipsed by "A:1000 - [B,C]:1000" > That the "A:1000 - C:1000" TCB should be removed. More > importantly it should be prevent from retransmitting its > INIT message. If no action is taken that would be the > logical result as that it never received an INIT-ACK > response. > > There is no fortune-telling going on here. The INIT-ACK > clearly informs A that [B,C]:1000 is a single endpoint. > At the time that B/C generates each INIT-ACK it does not > have enough information to know that A is incorrectly > attempting to create two associations with identical > endpoints. After all, *no* records of prior INIT-ACKs > are supposed to be kept on the passive side. Doing so > creates a weakness for a denial-of-service attack. A (the > active side) has the first opportunity to identify and > correct the problem. > > If A wants to leave excess TCBs and indexes dangling around > that its business, but generating excess traffic (when there > was sufficient information to prevent those messages) is a > legitimate network issue. > > > > > > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Mar 3 13:59:48 2003 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07751 for ; Mon, 3 Mar 2003 13:59:47 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h23Ioh6N003127 for ; Mon, 3 Mar 2003 10:50:43 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h23Io5FW009328 for ; Mon, 3 Mar 2003 10:50:06 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h23ImGuX008303 for ; Mon, 3 Mar 2003 10:48:19 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h23IYWY00731 for ; Mon, 3 Mar 2003 20:34:32 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Mar 2003 20:31:16 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 20:31:15 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 20:31:15 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 20:31:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Mon, 3 Mar 2003 20:31:14 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLhq0gNm/vOgvKkSkWWTULiw5w5qwABEQBA From: To: Cc: , , X-OriginalArrivalTime: 03 Mar 2003 18:31:15.0638 (UTC) FILETIME=[1324F560:01C2E1B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA07751 Brian, snip... > > Now, Brian, can you tell me how in Earth would you > recognize that INIT > > from Host Z as coming from the same host you want to > connect with? > > > > Of course, I mean WITHOUT taking a look to the > parameters of the INIT > > chunk... > > Collision cannot be detected until COOKIE-ECHO is received > (RFC 2960 5.2.4 (B)). One does not have to peer into the > address list of the INIT or INIT-ACK to detect collision. You are completely right... You can detect it IF you have started to take measures WHEN answering the INIT chunk. See section 5.2.1 and 5.2.2 (and the modifications included in the Implementer's Guide for these sections), you behave differently if the INIT chunk comes from a known peer or not... things such as using the same VT in the INIT ACK than the one you used in your previously sent INIT, populating or not the Tie-Tags, etc... Come on, Brian, I know that you know A LOT about SCTP, so you should perfectly know this... why did you make this comment? don't you have any better answer? > > > > Because, I don't see how are you going to populate the > > > Tie Tags or > > > > not, if you don't know if the INIT comes from an > > > already established > > > > (but crashed) association (or one that it is being > > > formed, i.e., INIT > > > > collision)... > > > > > > You didn't read what I wrote in the last note. The > > > destination address and > > > port numbers are sufficient to find the existing TCB from > > > which the tie tags > > > are populated. It is not necessary to dig the address list. > > > > I cannot ask you this in a clearer way than written > above. Could you > > please answer me to THIS question? > > What has your question to do with lookin in address lists of INIT > and INIT-ACK? :-0 It seems that you simply want to waste our time... Don't tell me that you didn't understand what I was meaning... In any case, I copy it again here... > I am Host A and I want to establish the following association with > Host Z: (AddrA; PortA):(AddrZ; PortZ). > > I send and INIT from (AddrA; PortA) to (AddrZ; PortZ). > > Host Z happens to be multihomed. You DON'T know which are the > addresses of Host Z. Knowing this is outside SCTP, and if you happen > to know all the addresses of Host Z (in fact, of all the existing > hosts you could ever have an association with) BEFORE you ever got an > INIT or INIT ACK from Host Z, that's because you are in a SPECIAL > situation. Period. > > Host Z happens to have another address, AddrZ'. We are in an INIT > collision scenario, and Host Z sends you an INIT from (AddrZ'; PortZ) > to (AddrA; PortA). That INIT includes AddrZ inside a parameter. > > Now, Brian, can you tell me how in Earth would you recognize that INIT > from Host Z as coming from the same host you want to connect with? > > Of course, I mean WITHOUT taking a look to the parameters of the INIT > chunk... The INIT chunk coming from Host Z carries the information about AddrZ ONLY inside the INIT chunk as a parameter. That INIT comes from AddrZ', SO, you can only know that the host sending from AddrZ' ALSO uses AddrZ IF you take a look to those parameters inside the INIT chunk... Is it clear enough?. Once you know if the INIT came from a known source or not, you can construct the right INIT ACK to send... I imagine that you understood the idea some mails ago... And I think you are just trying to deviate the attention, so at the end we feel so tired of answering (and centering again the conversation) that we don't answer anymore, and it seems that "you won"... :-0 BR Iván Arias Rodríguez > --brian From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Mar 3 14:00:00 2003 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07770 for ; Mon, 3 Mar 2003 13:59:59 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h23IpR6N003801 for ; Mon, 3 Mar 2003 10:51:27 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h23IpQ28027339 for ; Mon, 3 Mar 2003 10:51:26 -0800 (PST) Received: from gw.openss7.com (IDENT:2l7zN2c32hY4Oa9OT4x/AnRaRwZDG0K7@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id h23IpcMp007703 for ; Mon, 3 Mar 2003 10:51:40 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:C9GKHKvuhIkS08EorO7ygOUa30LlkVtb@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23Ij8D19989; Mon, 3 Mar 2003 11:45:08 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23Ij7K17698; Mon, 3 Mar 2003 11:45:07 -0700 Date: Mon, 3 Mar 2003 11:45:07 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: rrs@cisco.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303114507.B16782@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Mon, Mar 03, 2003 at 08:31:14PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Mon, 03 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > snip... > > > > Now, Brian, can you tell me how in Earth would you > > recognize that INIT > > > from Host Z as coming from the same host you want to > > connect with? > > > > > > Of course, I mean WITHOUT taking a look to the > > parameters of the INIT > > > chunk... > > > > Collision cannot be detected until COOKIE-ECHO is received > > (RFC 2960 5.2.4 (B)). One does not have to peer into the > > address list of the INIT or INIT-ACK to detect collision. > > You are completely right... You can detect it IF you have started to > take measures WHEN answering the INIT chunk. See section 5.2.1 and > 5.2.2 (and the modifications included in the Implementer's Guide for > these sections), you behave differently if the INIT chunk comes from a > known peer or not... things such as using the same VT in the INIT ACK > than the one you used in your previously sent INIT, populating or not > the Tie-Tags, etc... > > Come on, Brian, I know that you know A LOT about SCTP, so you should > perfectly know this... why did you make this comment? don't you have > any better answer? > > > > > > Because, I don't see how are you going to populate the > > > > Tie Tags or > > > > > not, if you don't know if the INIT comes from an > > > > already established > > > > > (but crashed) association (or one that it is being > > > > formed, i.e., INIT > > > > > collision)... > > > > > > > > You didn't read what I wrote in the last note. The > > > > destination address and > > > > port numbers are sufficient to find the existing TCB from > > > > which the tie tags > > > > are populated. It is not necessary to dig the address list. > > > > > > I cannot ask you this in a clearer way than written > > above. Could you > > > please answer me to THIS question? > > > > What has your question to do with lookin in address lists of INIT > > and INIT-ACK? > > :-0 > > It seems that you simply want to waste our time... Don't tell me that > you didn't understand what I was meaning... In any case, I copy it > again here... > > > I am Host A and I want to establish the following association with > > Host Z: (AddrA; PortA):(AddrZ; PortZ). > > > > I send and INIT from (AddrA; PortA) to (AddrZ; PortZ). > > > > Host Z happens to be multihomed. You DON'T know which are the > > addresses of Host Z. Knowing this is outside SCTP, and if you happen > > to know all the addresses of Host Z (in fact, of all the existing > > hosts you could ever have an association with) BEFORE you ever got an > > INIT or INIT ACK from Host Z, that's because you are in a SPECIAL > > situation. Period. > > > > Host Z happens to have another address, AddrZ'. We are in an INIT > > collision scenario, and Host Z sends you an INIT from (AddrZ'; PortZ) > > to (AddrA; PortA). That INIT includes AddrZ inside a parameter. > > > > Now, Brian, can you tell me how in Earth would you recognize that INIT > > from Host Z as coming from the same host you want to connect with? > > > > Of course, I mean WITHOUT taking a look to the parameters of the INIT > > chunk... > > The INIT chunk coming from Host Z carries the information about AddrZ > ONLY inside the INIT chunk as a parameter. That INIT comes from > AddrZ', SO, you can only know that the host sending from AddrZ' ALSO > uses AddrZ IF you take a look to those parameters inside the INIT > chunk... Is it clear enough?. Once you know if the INIT came from a > known source or not, you can construct the right INIT ACK to send... If by "known source" you mean a fully formed TCB exists, then the information from the IP and SCTP headers is sufficent to identify the existing TCB. It is not necessary to look in the address list do this. If by "rigth INIT ACK" you mean populating tie tags, then all that needs to be known is whether a TCB exists or not. There is no choice but to respond to both INITs. All that needs to be determined is whether a fully formed TCB exists or not. The IP and SCTP header information is sufficient to do this. No need to look in the source address list of the INIT. > > I imagine that you understood the idea some mails ago... And I think > you are just trying to deviate the attention, so at the end we feel so > tired of answering (and centering again the conversation) that we > don't answer anymore, and it seems that "you won"... :-0 Not at all. Listen: one does not have to look in the address list of an INIT or INIT-ACK ever. The information in the IP and SCTP headers of the INIT and INIT-ACK can always be sufficient to idenitfy whether there is an existing fully formed TCB or not. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Mar 3 14:24:01 2003 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08657 for ; Mon, 3 Mar 2003 14:24:01 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h23JFg56014118 for ; Mon, 3 Mar 2003 11:15:42 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h23JF4O5029079 for ; Mon, 3 Mar 2003 11:15:04 -0800 (PST) Received: from gw.openss7.com (IDENT:zoy7P4mesvcausOiExHWJdBm4/ao+HKB@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h23JCYuX028590 for ; Mon, 3 Mar 2003 11:12:34 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:G6GYUTic+sNrpgxSm48foyGkQ3rQXJIY@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23J9AD20467; Mon, 3 Mar 2003 12:09:10 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23J9A918607; Mon, 3 Mar 2003 12:09:10 -0700 Date: Mon, 3 Mar 2003 12:09:09 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303120909.E16782@openss7.org> Reply-To: bidulock@openss7.org References: <20030303102928.A15597@openss7.org> <3E639BF3.6010403@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E639BF3.6010403@cisco.com>; from rrs@cisco.com on Mon, Mar 03, 2003 at 12:16:19PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > > > > > >> Aha... they are sufficient... yes... of course... > >> > >> I am Host A and I want to establish the following association with > >> Host Z: (AddrA; PortA):(AddrZ; PortZ). > >> > >> I send and INIT from (AddrA; PortA) to (AddrZ; PortZ). > >> > >> Host Z happens to be multihomed. You DON'T know which are the > >> addresses of Host Z. Knowing this is outside SCTP, and if you happen > >> to know all the addresses of Host Z (in fact, of all the existing > >> hosts you could ever have an association with) BEFORE you ever got an > >> INIT or INIT ACK from Host Z, that's because you are in a SPECIAL > >> situation. Period. > >> > >> Host Z happens to have another address, AddrZ'. We are in an INIT > >> collision scenario, and Host Z sends you an INIT from (AddrZ'; PortZ) > >> to (AddrA; PortA). That INIT includes AddrZ inside a parameter. > >> > >> Now, Brian, can you tell me how in Earth would you recognize that INIT > >> from Host Z as coming from the same host you want to connect with? > >> > >> Of course, I mean WITHOUT taking a look to the parameters of the INIT > >> chunk... > >> > >> > > > >Collision cannot be detected until COOKIE-ECHO is received > >(RFC 2960 5.2.4 (B)). One does not have to peer into the > >address list of the INIT or INIT-ACK to detect collision. > > > > > > Collision detection is not what Ivan is talking about.. you MUST find > the old association (if there is one) so you can populate the tie-tags so > you CAN do a collision detection as discussed in that section. > > You cannot do the detection without the tie tags being properly > populated, and you cannot populate the tie-tags without this > address lookup.. unless of course you have a special implementation > (as you do) that has pre-knowledge on all of the addresses the peer has. > Please think beyond your specialized implementation where you > have NO KNOWLEDGE of any of the peer addresses... > > Then maybe you can answer Ivan's question above, which you seem > to be ignoring.. The information from the IP and SCTP header is sufficient to identify a fully formed TCB and populate tie tags. There is no need to look in the source address list of the INIT or INIT-ACK. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Mar 3 14:24:04 2003 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08670 for ; Mon, 3 Mar 2003 14:24:03 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h23JEeP7011608; Mon, 3 Mar 2003 11:14:40 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEA21312; Mon, 3 Mar 2003 11:14:54 -0800 (PST) Message-ID: <3E63A9AD.4070209@cisco.com> Date: Mon, 03 Mar 2003 13:14:53 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Caitlin Bestler , sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030303103316.B15597@openss7.org> <20030303113213.A16782@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Caitlin, > >On Mon, 03 Mar 2003, Caitlin Bestler wrote: > > > >>On 3/3/03, Brian F. G. Bidulock wrote: >> >> >> >>>Caitlin, >>> >>>What excess traffic? None of the actions in RFC 2960 >>>section 5.2.4 can be detected until COOKIE-ECHO is >>>received. Attempting to determine these things from the >>>INIT or INIT-ACK is attempting to fortell the future. The >>>result of trying to fortell the future is valid init >>>attempts being refused. >>> >>>--brian >>> >>> >>>On Mon, 03 Mar 2003, Caitlin Bestler wrote: >>> >>> >>> >>>>Brian, >>>> >>>>Is your point that there is no need to check the >>>>INIT-ACK when it arrives because the other end can check >>>>the INIT-ACK inside the State Cookie in the COOKIE-ECHO? >>>> >>>>If so, what is the benefit of deferring the check? The >>>>extra costs, delay and a redundant COOKIE-ECHO, are >>>>admittedly minor. But why tolerate any excess network >>>>traffic that could have been prevented by simply using >>>>the data already available? >>>> >>>> >>>>Caitlin Bestler >>>>http://asomi.com/CaitlinBestler/ >>>> >>>> >>INIT from A:1000 to B:1000 ------------------------------> >>INIT form A:1000 to C:1000 ------------------------------> >><-------------------------------------INIT-ACK TO A:1000 >> from [b,c]:1000 >><-------------------------------------INIT-ACK TO A:1000 >> from [b,c]:1000 >> >> > >Oh, you are back to this example. There is no need to peer >into the address lists to do what is required here. The >information from the IP and SCTP headers of the INIT-ACK is >sufficient. > > Is not this the example that Caitlin as always been talking about?? >If these are two INITs for the same connection, then VT (and >port pair and destination address) in the INIT-ACK is sufficient >to identify the association and deem one redundant. No need to >examine address lists. Only one COOKIE-ECHO will be sent. > > And how are the V-Tag's going to help? Each V-Tag of the two INIT's above SHOULD be different... the one to B should be say X and the one to C should be say Y... How will hashing the Vtags make it so you find that the two are redundant.. Remember, there is NO address list in the TCB on A, A only has one address... (having an address list is a specialization for a NON-general stack). >If these are INITs for two different connections then the >TCB of the first INIT-ACK is expanded. The TCB is again >identified by VT (and port pair and destination address). >There is no need to peer into the source address list. >The second INIT-ACK to arrive has a destination address which >corresponds to the TCB of the first. VT, destination >address, source address and port pair is sufficient to identify >that the second INIT-ACK belongs to the first TCB. Only one >COOKIE-ECHO will be sent. > >Again: it is not necessary to look in the address list of the >INIT or INIT-ACK. The IP and SCTP header has all of the >information necessary to identify an existing TCB. > >Do you see yet? > No, and I don't think your statements above work unless A has pre-knowledge about what addresses the peer will have... which is NOT what Caitlin is showing here.. we are discussing a general purpose stack.. not the specialized one you keep coming back to. R > >--brian > > > >> >>If A properly expands the scope of the first association's >>TCB upon receipt to cover both b and c, then the second >>INIT-ACK will be recognized as redundant. Only a single >>COOKIE-ECHO will be sent. >> >>If A shirks the responsibility of examining the address >>list within the INIT-ACK, and instead relies upon B/C to >>do the check when it/they process their COOKIE-ECHOEs >>then there will be *two* COOKIE-ECHOs sent. The second >>COOKIE-ECHO is an excess message that should be prevented. >> >>Further, A SHOULD also realize that the TCB it created for >>"A:1000 - C:1000" has been eclipsed by "A:1000 - [B,C]:1000" >>That the "A:1000 - C:1000" TCB should be removed. More >>importantly it should be prevent from retransmitting its >>INIT message. If no action is taken that would be the >>logical result as that it never received an INIT-ACK >>response. >> >>There is no fortune-telling going on here. The INIT-ACK >>clearly informs A that [B,C]:1000 is a single endpoint. >>At the time that B/C generates each INIT-ACK it does not >>have enough information to know that A is incorrectly >>attempting to create two associations with identical >>endpoints. After all, *no* records of prior INIT-ACKs >>are supposed to be kept on the passive side. Doing so >>creates a weakness for a denial-of-service attack. A (the >>active side) has the first opportunity to identify and >>correct the problem. >> >>If A wants to leave excess TCBs and indexes dangling around >>that its business, but generating excess traffic (when there >>was sufficient information to prevent those messages) is a >>legitimate network issue. >> >> >> >> >> >> >>Caitlin Bestler >>http://asomi.com/CaitlinBestler/ >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Mar 3 14:28:20 2003 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08859 for ; Mon, 3 Mar 2003 14:28:19 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h23JNV56019879; Mon, 3 Mar 2003 11:23:31 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEA22885; Mon, 3 Mar 2003 11:23:29 -0800 (PST) Message-ID: <3E63ABB1.2030201@cisco.com> Date: Mon, 03 Mar 2003 13:23:29 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: bidulock@openss7.org, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ivan: I, like you, am frustrated by Brian's failure to see the clear arguments that You, Caitlin and I have made. Brian seems to be in one of three catagories: either: A) So focused on his own specialized implementation (which has pre-knowledge of all possible peer addresses) that he can NOT understand the points we are making. B) Just plain does not understand SCTP (this I just can't believe) or C) is just making trouble and wasting all of our time. If its A), then no amount of bandwidth we dedicate to answering Brian will make any difference. If it is B), which I doubt, then Brian appears not to be listening so why waste everyones time, and if it is C).. well there is no sense in answering.. I think it is time to forget about Brian's disussion on this subject and just ignore further posts ... Otherwise we all will just keep wasting our time... R Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > snip... > > > >>> Now, Brian, can you tell me how in Earth would you >>> >>> >>recognize that INIT >> >> >>> from Host Z as coming from the same host you want to >>> >>> >>connect with? >> >> >>> Of course, I mean WITHOUT taking a look to the >>> >>> >>parameters of the INIT >> >> >>> chunk... >>> >>> >>Collision cannot be detected until COOKIE-ECHO is received >>(RFC 2960 5.2.4 (B)). One does not have to peer into the >>address list of the INIT or INIT-ACK to detect collision. >> >> > > You are completely right... You can detect it IF you have started to take measures WHEN answering the INIT chunk. See section 5.2.1 and 5.2.2 (and the modifications included in the Implementer's Guide for these sections), you behave differently if the INIT chunk comes from a known peer or not... things such as using the same VT in the INIT ACK than the one you used in your previously sent INIT, populating or not the Tie-Tags, etc... > > Come on, Brian, I know that you know A LOT about SCTP, so you should perfectly know this... why did you make this comment? don't you have any better answer? > > > >>>>> Because, I don't see how are you going to populate the >>>>> >>>>> >>>>Tie Tags or >>>> >>>> >>>>> not, if you don't know if the INIT comes from an >>>>> >>>>> >>>>already established >>>> >>>> >>>>> (but crashed) association (or one that it is being >>>>> >>>>> >>>>formed, i.e., INIT >>>> >>>> >>>>> collision)... >>>>> >>>>> >>>>You didn't read what I wrote in the last note. The >>>>destination address and >>>>port numbers are sufficient to find the existing TCB from >>>>which the tie tags >>>>are populated. It is not necessary to dig the address list. >>>> >>>> >>> I cannot ask you this in a clearer way than written >>> >>> >>above. Could you >> >> >>> please answer me to THIS question? >>> >>> >>What has your question to do with lookin in address lists of INIT >>and INIT-ACK? >> >> > > :-0 > > It seems that you simply want to waste our time... Don't tell me that you didn't understand what I was meaning... In any case, I copy it again here... > > > >> I am Host A and I want to establish the following association with >> Host Z: (AddrA; PortA):(AddrZ; PortZ). >> >> I send and INIT from (AddrA; PortA) to (AddrZ; PortZ). >> >> Host Z happens to be multihomed. You DON'T know which are the >> addresses of Host Z. Knowing this is outside SCTP, and if you happen >> to know all the addresses of Host Z (in fact, of all the existing >> hosts you could ever have an association with) BEFORE you ever got an >> INIT or INIT ACK from Host Z, that's because you are in a SPECIAL >> situation. Period. >> >> Host Z happens to have another address, AddrZ'. We are in an INIT >> collision scenario, and Host Z sends you an INIT from (AddrZ'; PortZ) >> to (AddrA; PortA). That INIT includes AddrZ inside a parameter. >> >> Now, Brian, can you tell me how in Earth would you recognize that INIT >> from Host Z as coming from the same host you want to connect with? >> >> Of course, I mean WITHOUT taking a look to the parameters of the INIT >> chunk... >> >> > > The INIT chunk coming from Host Z carries the information about AddrZ ONLY inside the INIT chunk as a parameter. That INIT comes from AddrZ', SO, you can only know that the host sending from AddrZ' ALSO uses AddrZ IF you take a look to those parameters inside the INIT chunk... Is it clear enough?. Once you know if the INIT came from a known source or not, you can construct the right INIT ACK to send... > > I imagine that you understood the idea some mails ago... And I think you are just trying to deviate the attention, so at the end we feel so tired of answering (and centering again the conversation) that we don't answer anymore, and it seems that "you won"... :-0 > > BR Iván Arias Rodríguez > > > >>--brian >> > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Mar 3 14:48:46 2003 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09688 for ; Mon, 3 Mar 2003 14:48:45 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h23JdhHK001833 for ; Mon, 3 Mar 2003 11:39:43 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h23Je1rQ018653 for ; Mon, 3 Mar 2003 11:40:01 -0800 (PST) Received: from gw.openss7.com (IDENT:bbCrRXanGAl4hz14aWiubgsFwQ+jyhsh@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h23JatuX020590 for ; Mon, 3 Mar 2003 11:36:58 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:ELYkyu1BCt0XVYA1j2Ra57J0dGGT1zh9@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23JWXD20863; Mon, 3 Mar 2003 12:32:33 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23JWXX19507; Mon, 3 Mar 2003 12:32:33 -0700 Date: Mon, 3 Mar 2003 12:32:32 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Caitlin Bestler , sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303123232.F16782@openss7.org> Reply-To: bidulock@openss7.org References: <20030303103316.B15597@openss7.org> <20030303113213.A16782@openss7.org> <3E63A9AD.4070209@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E63A9AD.4070209@cisco.com>; from rrs@cisco.com on Mon, Mar 03, 2003 at 01:14:53PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >Caitlin, > > > >On Mon, 03 Mar 2003, Caitlin Bestler wrote: > > > > > > > >>On 3/3/03, Brian F. G. Bidulock wrote: > >> > >> > >> > >>>Caitlin, > >>> > >>>What excess traffic? None of the actions in RFC 2960 > >>>section 5.2.4 can be detected until COOKIE-ECHO is > >>>received. Attempting to determine these things from the > >>>INIT or INIT-ACK is attempting to fortell the future. The > >>>result of trying to fortell the future is valid init > >>>attempts being refused. > >>> > >>>--brian > >>> > >>> > >>>On Mon, 03 Mar 2003, Caitlin Bestler wrote: > >>> > >>> > >>> > >>>>Brian, > >>>> > >>>>Is your point that there is no need to check the > >>>>INIT-ACK when it arrives because the other end can check > >>>>the INIT-ACK inside the State Cookie in the COOKIE-ECHO? > >>>> > >>>>If so, what is the benefit of deferring the check? The > >>>>extra costs, delay and a redundant COOKIE-ECHO, are > >>>>admittedly minor. But why tolerate any excess network > >>>>traffic that could have been prevented by simply using > >>>>the data already available? > >>>> > >>>> > >>>>Caitlin Bestler > >>>>http://asomi.com/CaitlinBestler/ > >>>> > >>>> > >>INIT from A:1000 to B:1000 ------------------------------> > >>INIT form A:1000 to C:1000 ------------------------------> > >><-------------------------------------INIT-ACK TO A:1000 > >> from [b,c]:1000 > >><-------------------------------------INIT-ACK TO A:1000 > >> from [b,c]:1000 > >> > >> > > > >Oh, you are back to this example. There is no need to peer > >into the address lists to do what is required here. The > >information from the IP and SCTP headers of the INIT-ACK is > >sufficient. > > > > > Is not this the example that Caitlin as always been talking about?? I'm sorry, I was confusing Ivan and Caitlin's examples. > > >If these are two INITs for the same connection, then VT (and > >port pair and destination address) in the INIT-ACK is sufficient > >to identify the association and deem one redundant. No need to > >examine address lists. Only one COOKIE-ECHO will be sent. > > > > > > And how are the V-Tag's going to help? Each V-Tag of the two > INIT's above SHOULD be different... the one to B should be > say X and the one to C should be say Y... > > How will hashing the Vtags make it so you find that the > two are redundant.. Remember, there is NO address list in > the TCB on A, A only has one address... (having an address > list is a specialization for a NON-general stack). > > > > >If these are INITs for two different connections then the > >TCB of the first INIT-ACK is expanded. The TCB is again > >identified by VT (and port pair and destination address). > >There is no need to peer into the source address list. > >The second INIT-ACK to arrive has a destination address which > >corresponds to the TCB of the first. VT, destination > >address, source address and port pair is sufficient to identify > >that the second INIT-ACK belongs to the first TCB. Only one > >COOKIE-ECHO will be sent. > > > >Again: it is not necessary to look in the address list of the > >INIT or INIT-ACK. The IP and SCTP header has all of the > >information necessary to identify an existing TCB. > > > >Do you see yet? > > > No, and I don't think your statements above work unless > A has pre-knowledge about what addresses the peer will > have... which is NOT what Caitlin is showing here.. we > are discussing a general purpose stack.. not the specialized > one you keep coming back to. Read above. No prior knowledge of addresses is necessary. The above works fine without looking in address lists. The IP/SCTP headers are sufficient. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Mar 3 15:06:10 2003 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10410 for ; Mon, 3 Mar 2003 15:06:10 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h23K17HK015474 for ; Mon, 3 Mar 2003 12:01:07 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h23K1QQY022871 for ; Mon, 3 Mar 2003 12:01:26 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h23K1XCZ003347 for ; Mon, 3 Mar 2003 12:01:36 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h23JjWY29945 for ; Mon, 3 Mar 2003 21:45:32 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Mar 2003 21:42:16 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 21:42:16 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 21:42:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Mon, 3 Mar 2003 21:42:14 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLhuUoevoe2rjVgSpyFdoJbsesg8QAAvy2g From: To: , Cc: , X-OriginalArrivalTime: 03 Mar 2003 19:42:15.0663 (UTC) FILETIME=[FE512FF0:01C2E1BC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA10410 Brian, > > >Collision cannot be detected until COOKIE-ECHO is received > > >(RFC 2960 5.2.4 (B)). One does not have to peer into the > > >address list of the INIT or INIT-ACK to detect collision. > > > > > > > > > > Collision detection is not what Ivan is talking about.. you > MUST find > > the old association (if there is one) so you can populate > the tie-tags so > > you CAN do a collision detection as discussed in that section. > > > > You cannot do the detection without the tie tags being properly > > populated, and you cannot populate the tie-tags without this > > address lookup.. unless of course you have a special implementation > > (as you do) that has pre-knowledge on all of the addresses > the peer has. > > Please think beyond your specialized implementation where you > > have NO KNOWLEDGE of any of the peer addresses... > > > > Then maybe you can answer Ivan's question above, which you seem > > to be ignoring.. > > The information from the IP and SCTP header is sufficient to identify > a fully formed TCB and populate tie tags. There is no need to look in > the source address list of the INIT or INIT-ACK. > > --brian Can you give us any practical example (I mean, with Addresses, VTs, ports, states and stuff) of the cases we are discussing, instead of continue doing cut&paste with the previous paragraph? That might be more convincing than simply trusting you just because... especially since we "doubt" you are right :-/ It is a pity that only you know how to do it and you don't want to share that knowledge with us... :-( BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Mar 3 15:19:15 2003 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11461 for ; Mon, 3 Mar 2003 15:19:15 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h23KAI6N005766 for ; Mon, 3 Mar 2003 12:10:18 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h23KAHnO012651 for ; Mon, 3 Mar 2003 12:10:17 -0800 (PST) Received: from gw.openss7.com (IDENT:Ju6jUfTld2XwiL9CXCYYjqau3P5014sA@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h23K9pnl021182 for ; Mon, 3 Mar 2003 12:09:56 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:QmvviyppAOJcpdysXG+ejSicEnTjaeDa@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23K3jD21317; Mon, 3 Mar 2003 13:03:45 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23K3iD20159; Mon, 3 Mar 2003 13:03:44 -0700 Date: Mon, 3 Mar 2003 13:03:44 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303130344.G16782@openss7.org> Reply-To: bidulock@openss7.org References: <3E63ABB1.2030201@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E63ABB1.2030201@cisco.com>; from rrs@cisco.com on Mon, Mar 03, 2003 at 01:23:29PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, Please show me a case where it is necessary to look in the source address lists in the INIT or INIT-ACK. It is not necessary in Caitlin's example and it is not necessary in Ivan's. With your wide knowledge of SCTP, can you provide a case where it is necessary? (Bear in mind that VT can be used to associate INIT-ACK with INIT and pre-knowledge of peer addresses is not necessary). My point is that it is never necessary to look in the source address list of the INIT, and with VT approach (fully under the control of the implementation) it is never necessary to look in the source address list of the INIT-ACK. --brian On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > Ivan: > > I, like you, am frustrated by Brian's failure to see the clear arguments > that You, Caitlin and I have made. > > Brian seems to be in one of three catagories: > > either: > > A) So focused on his own specialized implementation (which has > pre-knowledge of > all possible peer addresses) that he can NOT understand the points > we are making. Pre-knowledge of peer addresses is not necessary for proper operation in Caitlin or Ivan's examples and it is still not necessary to scan the source address list inside the INIT or INIT-ACK. > > B) Just plain does not understand SCTP (this I just can't believe) > > or > > C) is just making trouble and wasting all of our time. > > > If its A), then no amount of bandwidth we dedicate to answering Brian > will make any difference. > > If it is B), which I doubt, then Brian appears not to be listening so > why waste everyones time, > > and if it is C).. well there is no sense in answering.. > > I think it is time to forget about Brian's disussion on this subject and > just ignore further posts ... > > Otherwise we all will just keep wasting our time... Please just provide a case in RFC 2960 where it is necessary to look in source address lists in INIT or INIT-ACK (remember valid VT approach for INIT-ACK), or remove the SHOULD from the IG on same. Or could someone point out precisely where in Caitlin or Ivan's examples they think it is necessary to look at source address lists (beyond the IP header) for proper operation (remember VT approach)? --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Mar 3 15:36:20 2003 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11939 for ; Mon, 3 Mar 2003 15:36:19 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h23KTEHK002593; Mon, 3 Mar 2003 12:29:14 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEA34112; Mon, 3 Mar 2003 12:29:32 -0800 (PST) Message-ID: <3E63BB2B.1080504@cisco.com> Date: Mon, 03 Mar 2003 14:29:31 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <3E63ABB1.2030201@cisco.com> <20030303130344.G16782@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >Please show me a case where it is necessary to look in the source >address lists in the INIT or INIT-ACK. It is not necessary in >Caitlin's example and it is not necessary in Ivan's. > >With your wide knowledge of SCTP, can you provide a case where it >is necessary? (Bear in mind that VT can be used to associate >INIT-ACK with INIT and pre-knowledge of peer addresses is not >necessary). > >My point is that it is never necessary to look in the source address >list of the INIT, and with VT approach (fully under the control of the >implementation) it is never necessary to look in the source address >list of the INIT-ACK. > > Brian: We have all given you cases... once again I will give you one: E-A E-Z 1 ------------INIT(IP-A,TagX) to:IP-Z from:IP-A-------------------------> <-----------------------to:IP-A from:IP-Z' V-TagX:INIT-ACK(Vtag:Z, IP-Z,IP-Z') 2 At point 1 Endpoint A does NOT know any address but IP-Z for its potential peer. At point 2, yes you can lookup via hash the Tag X to find a endpoint that sent a INIT recently, but you cannot find the TCB... Your code, I looked, will do the hash and then compare its known addresses (remember its list ONLY has IP-Z) to the incoming address IP-Z' .. and it will NOT match and start looking through the alternative hash buckets.. and of course will NOT find any. The only reason your code would find the TCB is because you have pre-stored IP-Z and IP-Z' in E-A's TCB that is forming with E-Z... This is a specialized case ... yes I understand why you do it.. in a SS7 world this is very very valid to do.. but NOT in a general purpose protocol stack which may hit any web server out in the Big I that may have any number of addresses that are NOT listed anywhere... Please think beyond your implementation.. or at least look what would happen to your implemenation did not have IP-Z' listed in E-A's list of addresses of the peer at the time the INIT-ACK arrives.. It just plain does not work.. This is besides all of the other corner type cases.. they happen but, rarely, that Caitlin and Ivan have brought up. I would not want to make the requirement to dig through the INIT/INIT-ACK a MUST.. since this would exclude specialized implementations, like yours, making use of a stricter set of requirements on the user for the sake of an optimization.. but for a general purpose implementation we need to advise implementors to do this.. If you can't understand what I just wrote I am sorry.. I just don't have the cycles to devote to this anymore.. R At point 2, when the >--brian > >On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Ivan: >> >>I, like you, am frustrated by Brian's failure to see the clear arguments >>that You, Caitlin and I have made. >> >>Brian seems to be in one of three catagories: >> >>either: >> >>A) So focused on his own specialized implementation (which has >>pre-knowledge of >> all possible peer addresses) that he can NOT understand the points >>we are making. >> >> > >Pre-knowledge of peer addresses is not necessary for proper operation >in Caitlin or Ivan's examples and it is still not necessary to scan the >source address list inside the INIT or INIT-ACK. > > > >>B) Just plain does not understand SCTP (this I just can't believe) >> >>or >> >>C) is just making trouble and wasting all of our time. >> >> >>If its A), then no amount of bandwidth we dedicate to answering Brian >>will make any difference. >> >>If it is B), which I doubt, then Brian appears not to be listening so >>why waste everyones time, >> >>and if it is C).. well there is no sense in answering.. >> >>I think it is time to forget about Brian's disussion on this subject and >>just ignore further posts ... >> >>Otherwise we all will just keep wasting our time... >> >> > >Please just provide a case in RFC 2960 where it is necessary to look >in source address lists in INIT or INIT-ACK (remember valid VT approach >for INIT-ACK), or remove the SHOULD from the IG on same. > >Or could someone point out precisely where in Caitlin or Ivan's examples >they think it is necessary to look at source address lists (beyond the IP >header) for proper operation (remember VT approach)? > >--brian > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Mar 3 15:53:48 2003 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12494 for ; Mon, 3 Mar 2003 15:53:47 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h23Kit56018900 for ; Mon, 3 Mar 2003 12:44:55 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h23Kisx7024240 for ; Mon, 3 Mar 2003 12:44:54 -0800 (PST) Received: from gw.openss7.com (IDENT:9c2DifTnD+JMNhS2Sg1aeNj51a0ny9ce@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h23KgKrO018764 for ; Mon, 3 Mar 2003 12:42:22 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:Don3cjvswsvFo51ccrJuXxXvYY4uwa1r@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23Kc0D21751; Mon, 3 Mar 2003 13:38:00 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23Kc0b20661; Mon, 3 Mar 2003 13:38:00 -0700 Date: Mon, 3 Mar 2003 13:37:59 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: rrs@cisco.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303133759.H16782@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Mon, Mar 03, 2003 at 09:42:14PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Mon, 03 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > > > >Collision cannot be detected until COOKIE-ECHO is received > > > >(RFC 2960 5.2.4 (B)). One does not have to peer into the > > > >address list of the INIT or INIT-ACK to detect collision. > > > > > > > > > > > > > > Collision detection is not what Ivan is talking about.. you > > MUST find > > > the old association (if there is one) so you can populate > > the tie-tags so > > > you CAN do a collision detection as discussed in that section. > > > > > > You cannot do the detection without the tie tags being properly > > > populated, and you cannot populate the tie-tags without this > > > address lookup.. unless of course you have a special implementation > > > (as you do) that has pre-knowledge on all of the addresses > > the peer has. > > > Please think beyond your specialized implementation where you > > > have NO KNOWLEDGE of any of the peer addresses... > > > > > > Then maybe you can answer Ivan's question above, which you seem > > > to be ignoring.. > > > > The information from the IP and SCTP header is sufficient to identify > > a fully formed TCB and populate tie tags. There is no need to look in > > the source address list of the INIT or INIT-ACK. > > > > --brian > > Can you give us any practical example (I mean, with Addresses, VTs, > ports, states and stuff) of the cases we are discussing, instead of > continue doing cut&paste with the previous paragraph? > > That might be more convincing than simply trusting you just because... > especially since we "doubt" you are right :-/ > > It is a pity that only you know how to do it and you don't want to > share that knowledge with us... :-( > > BR Iván Arias Rodríguez Ivan, You example is the INIT collision example. Correct? Something like the following: Host A Host B/C INIT (VT:W, A:1000-->B:1000) (-) -------------\ TCB formed (A:1000<->B:1000) \ \ INIT (VT:X, C:1000-->A:1000) (B) \ /-------------------------------- \ / TCB formed (A:1000<->B/C:1000) \ / \-------------------------------------> / TCB found on A:1000<->B:1000 / Tie tags populated (VT:X, PT:0) / INIT-ACK (VT:Z, PT:W, C:1000-->A:1000) (B) <---------------------------------------------------------- TCB (VT=W) expanded to (A:1000<->B/C:1000) / <--------------/ Host A has no TCB for C:1000,A:1000, no tie tags populated. INIT-ACK (VT:Y, PT:X, A:1000->C:1000) (-) ----------------------------------------------------------> TCB found on VT=Z. COOKIE-ECHO (tie tags in cookie) ----------------------------------------------------------> Tie tags used to detect collision per 2960 5.2 case B. VT updated from Z to X. established. COOKIE-ECHO (no tie tags) <---------------------------------------------------------- TCB (VT=W) established. One association. VT:W, A:1000 <---> VT:X B/C:1000 <---------------------------------------------------------> Never needed to look in the source address list. Can your modify this in any way to make it necessary? --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Mar 3 16:07:20 2003 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12949 for ; Mon, 3 Mar 2003 16:07:19 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h23KwwP7012083 for ; Mon, 3 Mar 2003 12:58:58 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h23KxCU5019255 for ; Mon, 3 Mar 2003 12:59:12 -0800 (PST) Received: from gw.openss7.com (IDENT:LQbXaiQEMlAQYWgtQWHSvGj90l6GIBjU@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h23KvDrO001931 for ; Mon, 3 Mar 2003 12:57:15 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:GX62ax2bYuwoISWiCBgT0HRD/p6Jljzf@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23KrfD21934; Mon, 3 Mar 2003 13:53:41 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23Krfu20987; Mon, 3 Mar 2003 13:53:41 -0700 Date: Mon, 3 Mar 2003 13:53:41 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: rrs@cisco.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303135341.I16782@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Mon, Mar 03, 2003 at 09:42:14PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Mon, 03 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > > > >Collision cannot be detected until COOKIE-ECHO is received > > > >(RFC 2960 5.2.4 (B)). One does not have to peer into the > > > >address list of the INIT or INIT-ACK to detect collision. > > > > > > > > > > > > > > Collision detection is not what Ivan is talking about.. you > > MUST find > > > the old association (if there is one) so you can populate > > the tie-tags so > > > you CAN do a collision detection as discussed in that section. > > > > > > You cannot do the detection without the tie tags being properly > > > populated, and you cannot populate the tie-tags without this > > > address lookup.. unless of course you have a special implementation > > > (as you do) that has pre-knowledge on all of the addresses > > the peer has. > > > Please think beyond your specialized implementation where you > > > have NO KNOWLEDGE of any of the peer addresses... > > > > > > Then maybe you can answer Ivan's question above, which you seem > > > to be ignoring.. > > > > The information from the IP and SCTP header is sufficient to identify > > a fully formed TCB and populate tie tags. There is no need to look in > > the source address list of the INIT or INIT-ACK. > > > > --brian > > Can you give us any practical example (I mean, with Addresses, VTs, > ports, states and stuff) of the cases we are discussing, instead of > continue doing cut&paste with the previous paragraph? > > That might be more convincing than simply trusting you just because... > especially since we "doubt" you are right :-/ > > It is a pity that only you know how to do it and you don't want to > share that knowledge with us... :-( > > BR Iván Arias Rodríguez Ivan, Here, I believe, is Caitlan's example: HOST A HOST B/C INIT (VT:0 PT:X, A:1000->B:1000) --------------------------------------------------------------> TCB (VT:X, A:1000<->B:1000) No TCB INIT (VT:0 PT:Y, A:1000->C:1000) --------------------------------------------------------------> TCB (VT:Y, A:1000<->C:1000) No TCB INIT-ACK(VT:X, PT:W, C:1000->A:1000 (B)) <-------------------------------------------------------------- TCB found (VT:X) and expanded (VT:X, A:1000<->B/C:1000) INIT-ACK(VT:Y, PT:Z, C:1000->A:1000 (B)) <-------------------------------------------------------------- TCB found (A:1000<->C:1000) INIT-ACK discarded per RFC 2960 5.2.3. COOKIE-ECHO (VT:W) --------------------------------------------------------------> TCB established One association. (VT:X A:1000 <--> VT: W B/C:1000) <-------------------------------------------------------------> Never had to look in the source address list. Could you point out where you think it is necessary? --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Mar 3 16:28:19 2003 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13480 for ; Mon, 3 Mar 2003 16:28:18 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h23LJkP7010323; Mon, 3 Mar 2003 13:19:46 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEA41315; Mon, 3 Mar 2003 13:20:00 -0800 (PST) Message-ID: <3E63C6FF.9040104@cisco.com> Date: Mon, 03 Mar 2003 15:19:59 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030303135341.I16782@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Brian F. G. Bidulock wrote: >Ivan.Arias-Rodriguez, > >On Mon, 03 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > >> Brian, >> >> >> >>>>>Collision cannot be detected until COOKIE-ECHO is received >>>>>(RFC 2960 5.2.4 (B)). One does not have to peer into the >>>>>address list of the INIT or INIT-ACK to detect collision. >>>>> >>>>> >>>>> >>>>> >>>>Collision detection is not what Ivan is talking about.. you >>>> >>>> >>>MUST find >>> >>> >>>>the old association (if there is one) so you can populate >>>> >>>> >>>the tie-tags so >>> >>> >>>>you CAN do a collision detection as discussed in that section. >>>> >>>>You cannot do the detection without the tie tags being properly >>>>populated, and you cannot populate the tie-tags without this >>>>address lookup.. unless of course you have a special implementation >>>>(as you do) that has pre-knowledge on all of the addresses >>>> >>>> >>>the peer has. >>> >>> >>>>Please think beyond your specialized implementation where you >>>>have NO KNOWLEDGE of any of the peer addresses... >>>> >>>>Then maybe you can answer Ivan's question above, which you seem >>>>to be ignoring.. >>>> >>>> >>>The information from the IP and SCTP header is sufficient to identify >>>a fully formed TCB and populate tie tags. There is no need to look in >>>the source address list of the INIT or INIT-ACK. >>> >>>--brian >>> >>> >> Can you give us any practical example (I mean, with Addresses, VTs, >> ports, states and stuff) of the cases we are discussing, instead of >> continue doing cut&paste with the previous paragraph? >> >> That might be more convincing than simply trusting you just because... >> especially since we "doubt" you are right :-/ >> >> It is a pity that only you know how to do it and you don't want to >> share that knowledge with us... :-( >> >> BR Iván Arias Rodríguez >> >> > > >Ivan, > >Here, I believe, is Caitlan's example: > > > HOST A HOST B/C > > INIT (VT:0 PT:X, A:1000->B:1000) > --------------------------------------------------------------> > TCB (VT:X, A:1000<->B:1000) No TCB > > > INIT (VT:0 PT:Y, A:1000->C:1000) > --------------------------------------------------------------> > TCB (VT:Y, A:1000<->C:1000) No TCB > > > INIT-ACK(VT:X, PT:W, C:1000->A:1000 (B)) > <-------------------------------------------------------------- > TCB found (VT:X) and expanded (VT:X, A:1000<->B/C:1000) > > But you do look at the source address list here.. in processing the INIT-ACK. You must... and you also must look through and find the TCB with VT:Y unless you wish to leave it hanging.. I think this is Caitlin's point.. you must clean up this extra TCB... and you do that by looking at the peers address list and making sure you don't have a seperate TCB hanging around... You have just shown one example of looking at the address list in the INIT-ACK. R > > INIT-ACK(VT:Y, PT:Z, C:1000->A:1000 (B)) > <-------------------------------------------------------------- > TCB found (A:1000<->C:1000) > INIT-ACK discarded per RFC 2960 5.2.3. > > > COOKIE-ECHO (VT:W) > --------------------------------------------------------------> > TCB established > > One association. (VT:X A:1000 <--> VT: W B/C:1000) > <-------------------------------------------------------------> > > >Never had to look in the source address list. Could you point out where >you think it is necessary? > >--brian > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Mar 3 17:30:04 2003 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15339 for ; Mon, 3 Mar 2003 17:30:03 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h23MJ46N009230 for ; Mon, 3 Mar 2003 14:19:04 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h23MIQ7F014498 for ; Mon, 3 Mar 2003 14:18:26 -0800 (PST) Received: from gw.openss7.com (IDENT:8LfeKtdM0wMGyiSmOIBEtUf36FG5Wmqr@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h23MGXrO012696 for ; Mon, 3 Mar 2003 14:16:39 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:NBmxDTVc6uczr7hFBShmyulZ4YuQ2cm+@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23MC6D23139; Mon, 3 Mar 2003 15:12:06 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23MC6523289; Mon, 3 Mar 2003 15:12:06 -0700 Date: Mon, 3 Mar 2003 15:12:06 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303151206.J16782@openss7.org> Reply-To: bidulock@openss7.org References: <20030303135341.I16782@openss7.org> <3E63C6FF.9040104@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E63C6FF.9040104@cisco.com>; from rrs@cisco.com on Mon, Mar 03, 2003 at 03:19:59PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > > > > > >Ivan, > > > >Here, I believe, is Caitlan's example: > > > > > > HOST A HOST B/C > > > > INIT (VT:0 PT:X, A:1000->B:1000) > > --------------------------------------------------------------> > > TCB (VT:X, A:1000<->B:1000) No TCB > > > > > > INIT (VT:0 PT:Y, A:1000->C:1000) > > --------------------------------------------------------------> > > TCB (VT:Y, A:1000<->C:1000) No TCB > > > > > > INIT-ACK(VT:X, PT:W, C:1000->A:1000 (B)) > > <-------------------------------------------------------------- > > TCB found (VT:X) and expanded (VT:X, A:1000<->B/C:1000) > > > > > But you do look at the source address list here.. in > processing the INIT-ACK. You must... and > you also must look through and find the TCB > with VT:Y unless you wish to leave it hanging.. I look at the source address in the IP header of the INIT-ACK to find the TCB. The source address list is copied to the TCB without analysis as there is no need to check the IP addresses in the source address list for overlap. The IG passage I have the problem with is: D) When searching for a matching TCB upon reception of an INIT or INIT-ACK chunk the receiver SHOULD use not only the source address of the packet (containing the INIT or INIT-ACK) but the receiver SHOULD also use all valid address parameters contained within the chunk. I don't need to use the source address list within the INIT-ACK chunk to find the proper TCB above. I only need the source address of the packet: quite the opposite of what this IG passage claims. > > I think this is Caitlin's point.. you must clean up this > extra TCB... and you do that by looking at the peers address > list and making sure you don't have a seperate TCB hanging > around... You have just shown one example of looking at > the address list in the INIT-ACK. How the implementation cleans up extra TCBs is its own business and has no bearing on the passage in the IG. The passage says "When searching for a matching TCB". I don't see anywhere here where it is necessary to analyze the source address list in the INIT-ACK "[w]hen searching for a matching TCB." Could you modify the example to show such a case as stated in IG 2.18.2? --brian > > R > > > > > INIT-ACK(VT:Y, PT:Z, C:1000->A:1000 (B)) > > <-------------------------------------------------------------- > > TCB found (A:1000<->C:1000) > > INIT-ACK discarded per RFC 2960 5.2.3. > > > > > > COOKIE-ECHO (VT:W) > > --------------------------------------------------------------> > > TCB established > > > > One association. (VT:X A:1000 <--> VT: W B/C:1000) > > <-------------------------------------------------------------> > > > > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Mar 3 17:54:22 2003 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16244 for ; Mon, 3 Mar 2003 17:54:20 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h23MiYHK025633 for ; Mon, 3 Mar 2003 14:44:34 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h23MiHGc002581 for ; Mon, 3 Mar 2003 14:44:17 -0800 (PST) Received: from gw.openss7.com (IDENT:dPWrg9sk01ww5bHLzU5/Uuvg3np5MgtQ@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h23MiqCZ002171 for ; Mon, 3 Mar 2003 14:45:00 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:o0IY1Brod0Hy5UCKSCTYpMybuCHBEbrT@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23MdLD23622; Mon, 3 Mar 2003 15:39:21 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23MdLu24180; Mon, 3 Mar 2003 15:39:21 -0700 Date: Mon, 3 Mar 2003 15:39:21 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303153921.K16782@openss7.org> Reply-To: bidulock@openss7.org References: <3E63ABB1.2030201@cisco.com> <20030303130344.G16782@openss7.org> <3E63BB2B.1080504@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E63BB2B.1080504@cisco.com>; from rrs@cisco.com on Mon, Mar 03, 2003 at 02:29:31PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >Randall, > > > >Please show me a case where it is necessary to look in the source > >address lists in the INIT or INIT-ACK. It is not necessary in > >Caitlin's example and it is not necessary in Ivan's. > > > >With your wide knowledge of SCTP, can you provide a case where it > >is necessary? (Bear in mind that VT can be used to associate > >INIT-ACK with INIT and pre-knowledge of peer addresses is not > >necessary). > > > >My point is that it is never necessary to look in the source address > >list of the INIT, and with VT approach (fully under the control of the > >implementation) it is never necessary to look in the source address > >list of the INIT-ACK. > > > > > > Brian: > > We have all given you cases... once again I will give you one: > > E-A E-Z > > 1 > ------------INIT(IP-A,TagX) to:IP-Z from:IP-A-------------------------> > <-----------------------to:IP-A from:IP-Z' > V-TagX:INIT-ACK(Vtag:Z, IP-Z,IP-Z') > 2 > > At point 1 Endpoint A does NOT know any address but IP-Z for its > potential peer. > > At point 2, yes you can lookup via hash the Tag X to find a endpoint > that sent a INIT recently, but you cannot find the TCB... Your code, I > looked, will > do the hash and then compare its known addresses (remember its list > ONLY has IP-Z) to the incoming address IP-Z' .. and it will NOT match > and start looking through the alternative hash buckets.. and of course will > NOT find any. I don't know which of the three implementations you are looking at, but both in the current LiS STREAMS and Linux 2.4.18 kernel implementations INIT-ACKs are looked up on vtag in function sctp_lookup_vtag called from function sctp_lookup. sctp_lookup_vtag hashes on vtag only and matches only on vtag and sport when configured for fast verification. So, as you say above, it is not necessary to look in the source address list when searching for a TCB, contrary to IG section 2.18. > > The only reason your code would find the TCB is because you have > pre-stored IP-Z and IP-Z' in E-A's TCB that is forming with E-Z... > This is a specialized case ... yes I understand why you do it.. in a SS7 > world this is very very valid to do.. but NOT in a general purpose protocol > stack which may hit any web server out in the Big I that may have any > number of addresses that are NOT listed anywhere... > > Please think beyond your implementation.. or at least look what would > happen to your implemenation did not have IP-Z' listed in E-A's list of > addresses of the peer at the time the INIT-ACK arrives.. > > It just plain does not work.. This is besides all of the other corner type > cases.. they happen but, rarely, that Caitlin and Ivan have brought up. > > I would not want to make the requirement to dig through the INIT/INIT-ACK > a MUST.. since this would exclude specialized implementations, like > yours, making > use of a stricter set of requirements on the user for the sake of an > optimization.. but for a general purpose > implementation we need to advise implementors to do this.. > > If you can't understand what I just wrote I am sorry.. I just don't have the > cycles to devote to this anymore.. Well, the answer to Vijay's question (that started this thread) is: 1) Yes, you can ignore the source address list when searching for the TCB contrary to IG 2.18 if you have other mechanisms (e.g. unique VT generation and lookup, pre-known source addresses, or any number of other techniques) to find the appropriate TCB. 2) Nothing bad will happen if you don't look in the source address list if you otherwise meet the requirements of RFC 2960. In other words, IG 2.18 is just an implementation suggestion and an inappropriate use of the keyword "SHOULD." --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Mar 3 18:09:10 2003 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17203 for ; Mon, 3 Mar 2003 18:09:09 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h23MwNHK004220; Mon, 3 Mar 2003 14:58:23 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEA55935; Mon, 3 Mar 2003 14:58:42 -0800 (PST) Message-ID: <3E63DE21.3080304@cisco.com> Date: Mon, 03 Mar 2003 16:58:41 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030303135341.I16782@openss7.org> <3E63C6FF.9040104@cisco.com> <20030303151206.J16782@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > > >>>Ivan, >>> >>>Here, I believe, is Caitlan's example: >>> >>> >>> HOST A HOST B/C >>> >>> INIT (VT:0 PT:X, A:1000->B:1000) >>> --------------------------------------------------------------> >>> TCB (VT:X, A:1000<->B:1000) No TCB >>> >>> >>> INIT (VT:0 PT:Y, A:1000->C:1000) >>> --------------------------------------------------------------> >>> TCB (VT:Y, A:1000<->C:1000) No TCB >>> >>> >>> INIT-ACK(VT:X, PT:W, C:1000->A:1000 (B)) >>> <-------------------------------------------------------------- >>> TCB found (VT:X) and expanded (VT:X, A:1000<->B/C:1000) >>> >>> >>> >>> >>But you do look at the source address list here.. in >>processing the INIT-ACK. You must... and >>you also must look through and find the TCB >>with VT:Y unless you wish to leave it hanging.. >> >> > >I look at the source address in the IP header of the INIT-ACK to find >the TCB. The source address list is copied to the TCB without analysis >as there is no need to check the IP addresses in the source address list >for overlap. > So if the source address is NOT the address you sent the INIT to but instead it is one of the alternate addresses listed in the INIT-ACK (along with the original address that the INIT was sent to) how are you going to find the TCB... Your current code will.. ONLY because you have pre-listed in its TCB all of the addresses that might be present in the INIT-ACK.. This is fine for your very specialized stack NOT for a general purpose stack.. so you now have just proved my point as to where you must examine the INIT-ACK's address... thank you.. > >The IG passage I have the problem with is: > > D) When searching for a matching TCB upon reception of an INIT > or INIT-ACK chunk the receiver SHOULD use not only the > source address of the packet (containing the INIT or > INIT-ACK) but the receiver SHOULD also use all valid > address parameters contained within the chunk. > >I don't need to use the source address list within the INIT-ACK >chunk to find the proper TCB above. I only need the source address >of the packet: quite the opposite of what this IG passage claims. > > You are 100% wrong.. if you sent the INIT to IP-A and the source address is IP-B how will you find the TCB.. your implementation does ONLY because you pre-listed IP-B in the TCB of the sender of the INIT.. this is ok to do (that is why the SHOULD is there and NOT a MUST). But for MOST implementations that are general.. obviously NOT yours.. you must go through the INIT-ACK to find the TCB... How much clearer do you need Ivan, Caitlin and I to be.. we all understand this.. you seem not to since all you can see is your very very limited implementation that places requirements on the user to pre-know all addresses of the peer.. sorry this is ok for the SS7 world.. but it is NOT ok for a general stack... Expect the language to stay in... you are alone in your objections... > > >>I think this is Caitlin's point.. you must clean up this >>extra TCB... and you do that by looking at the peers address >>list and making sure you don't have a seperate TCB hanging >>around... You have just shown one example of looking at >>the address list in the INIT-ACK. >> >> > >How the implementation cleans up extra TCBs is its own business and >has no bearing on the passage in the IG. The passage says "When >searching for a matching TCB". > >I don't see anywhere here where it is necessary to analyze the source >address list in the INIT-ACK "[w]hen searching for a matching TCB." >Could you modify the example to show such a case as stated in IG 2.18.2? > > My previous email to you showed you such a case.. and you ignored it.. this email shows the very same case.. and you ignore it.. The ONLY reason your implementation works is because you require the user to preset all of the peers addresses in before sending an INIT.. Its ok to do, thats why the passage is a SHOULD.. the rest of us who are developing general purpose stacks that will make there way into a lot of varied products can NOT work in such a narrow way.. You are very much alone in your objections...Bottom line.. the passage remains as is..... R >--brian > > > > >>R >> >> >> >>> >>> INIT-ACK(VT:Y, PT:Z, C:1000->A:1000 (B)) >>> <-------------------------------------------------------------- >>> TCB found (A:1000<->C:1000) >>> INIT-ACK discarded per RFC 2960 5.2.3. >>> >>> >>> COOKIE-ECHO (VT:W) >>> --------------------------------------------------------------> >>> TCB established >>> >>> One association. (VT:X A:1000 <--> VT: W B/C:1000) >>> <-------------------------------------------------------------> >>> >>> >>> >>> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Mar 3 18:12:56 2003 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17552 for ; Mon, 3 Mar 2003 18:12:54 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h23N1B6N012004; Mon, 3 Mar 2003 15:01:11 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEA56324; Mon, 3 Mar 2003 15:01:10 -0800 (PST) Message-ID: <3E63DEB5.9000102@cisco.com> Date: Mon, 03 Mar 2003 17:01:09 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <3E63ABB1.2030201@cisco.com> <20030303130344.G16782@openss7.org> <3E63BB2B.1080504@cisco.com> <20030303153921.K16782@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian F. G. Bidulock wrote: >> >> >> >>>Randall, >>> >>>Please show me a case where it is necessary to look in the source >>>address lists in the INIT or INIT-ACK. It is not necessary in >>>Caitlin's example and it is not necessary in Ivan's. >>> >>>With your wide knowledge of SCTP, can you provide a case where it >>>is necessary? (Bear in mind that VT can be used to associate >>>INIT-ACK with INIT and pre-knowledge of peer addresses is not >>>necessary). >>> >>>My point is that it is never necessary to look in the source address >>>list of the INIT, and with VT approach (fully under the control of the >>>implementation) it is never necessary to look in the source address >>>list of the INIT-ACK. >>> >>> >>> >>> >>Brian: >> >>We have all given you cases... once again I will give you one: >> >>E-A E-Z >> >>1 >>------------INIT(IP-A,TagX) to:IP-Z from:IP-A-------------------------> >> <-----------------------to:IP-A from:IP-Z' >>V-TagX:INIT-ACK(Vtag:Z, IP-Z,IP-Z') >>2 >> >>At point 1 Endpoint A does NOT know any address but IP-Z for its >>potential peer. >> >>At point 2, yes you can lookup via hash the Tag X to find a endpoint >>that sent a INIT recently, but you cannot find the TCB... Your code, I >>looked, will >>do the hash and then compare its known addresses (remember its list >>ONLY has IP-Z) to the incoming address IP-Z' .. and it will NOT match >>and start looking through the alternative hash buckets.. and of course will >>NOT find any. >> >> > >I don't know which of the three implementations you are looking at, but >both in the current LiS STREAMS and Linux 2.4.18 kernel implementations >INIT-ACKs are looked up on vtag in function sctp_lookup_vtag called from >function sctp_lookup. sctp_lookup_vtag hashes on vtag only and matches >only on vtag and sport when configured for fast verification. > >So, as you say above, it is not necessary to look in the source address >list when searching for a TCB, contrary to IG section 2.18. > > > >>The only reason your code would find the TCB is because you have >>pre-stored IP-Z and IP-Z' in E-A's TCB that is forming with E-Z... >>This is a specialized case ... yes I understand why you do it.. in a SS7 >>world this is very very valid to do.. but NOT in a general purpose protocol >>stack which may hit any web server out in the Big I that may have any >>number of addresses that are NOT listed anywhere... >> >>Please think beyond your implementation.. or at least look what would >>happen to your implemenation did not have IP-Z' listed in E-A's list of >>addresses of the peer at the time the INIT-ACK arrives.. >> >>It just plain does not work.. This is besides all of the other corner type >>cases.. they happen but, rarely, that Caitlin and Ivan have brought up. >> >>I would not want to make the requirement to dig through the INIT/INIT-ACK >>a MUST.. since this would exclude specialized implementations, like >>yours, making >>use of a stricter set of requirements on the user for the sake of an >>optimization.. but for a general purpose >>implementation we need to advise implementors to do this.. >> >>If you can't understand what I just wrote I am sorry.. I just don't have the >>cycles to devote to this anymore.. >> >> > >Well, the answer to Vijay's question (that started this thread) is: > > 1) Yes, you can ignore the source address list when searching for the > TCB contrary to IG 2.18 if you have other mechanisms (e.g. unique > VT generation and lookup, pre-known source addresses, or any number > ^^^^^^^^^^^^^^^^^^^^^^ and here is the relevant thing you MUST do in conjunction with Brian's method for this... > of other techniques) to find the appropriate TCB. > > 2) Nothing bad will happen if you don't look in the source address list > if you otherwise meet the requirements of RFC 2960. > Except you won't have a general purpose stack that can be used except in a very very limited way.. R > > Other tr >In other words, IG 2.18 is just an implementation suggestion and an >inappropriate use of the keyword "SHOULD." > >--brian > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Mar 3 18:52:36 2003 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18573 for ; Mon, 3 Mar 2003 18:52:35 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h23NfYP7019077 for ; Mon, 3 Mar 2003 15:41:34 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h23NfmEP028285 for ; Mon, 3 Mar 2003 15:41:48 -0800 (PST) Received: from gw.openss7.com (IDENT:Y8tt7iuIEtUSP3KfNXQ1SnIHI5YBoL+h@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h23NfUnl014187 for ; Mon, 3 Mar 2003 15:41:33 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:/ihg/lsP7X4urtTZtW/CB4kX756Ne/d6@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23NaSD24545; Mon, 3 Mar 2003 16:36:28 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23NaS725646; Mon, 3 Mar 2003 16:36:28 -0700 Date: Mon, 3 Mar 2003 16:36:28 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303163628.N16782@openss7.org> Reply-To: bidulock@openss7.org References: <20030303135341.I16782@openss7.org> <3E63C6FF.9040104@cisco.com> <20030303151206.J16782@openss7.org> <3E63DE21.3080304@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E63DE21.3080304@cisco.com>; from rrs@cisco.com on Mon, Mar 03, 2003 at 04:58:41PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >Randall, > > > >On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > > > > > >>>Ivan, > >>> > >>>Here, I believe, is Caitlan's example: > >>> > >>> > >>> HOST A HOST B/C > >>> > >>> INIT (VT:0 PT:X, A:1000->B:1000) > >>> --------------------------------------------------------------> > >>> TCB (VT:X, A:1000<->B:1000) No TCB > >>> > >>> > >>> INIT (VT:0 PT:Y, A:1000->C:1000) > >>> --------------------------------------------------------------> > >>> TCB (VT:Y, A:1000<->C:1000) No TCB > >>> > >>> > >>> INIT-ACK(VT:X, PT:W, C:1000->A:1000 (B)) > >>> <-------------------------------------------------------------- > >>> TCB found (VT:X) and expanded (VT:X, A:1000<->B/C:1000) > >>> > >>> > >>> > >>> > >>But you do look at the source address list here.. in > >>processing the INIT-ACK. You must... and > >>you also must look through and find the TCB > >>with VT:Y unless you wish to leave it hanging.. > >> > >> > > > >I look at the source address in the IP header of the INIT-ACK to find > >the TCB. The source address list is copied to the TCB without analysis > >as there is no need to check the IP addresses in the source address list > >for overlap. > > > So if the source address is NOT the address you sent the INIT to but instead > it is one of the alternate addresses listed in the INIT-ACK (along with > the original address that the INIT was sent to) how are you going to > find the TCB... Your current code will.. ONLY because you have > pre-listed in its TCB all of the addresses that might be present > in the INIT-ACK.. I use VT. I don't need the source address list. Read what the example says: "TCB found (VT:X)" > > This is fine for your very specialized stack NOT for a general > purpose stack.. so you now have just proved my point as to > where you must examine the INIT-ACK's address... thank you.. I don't need to know the peer's addresses to find the TCB. The TCB is the TCB with VT:X, the same VT I sent in the INIT. > > > > > >The IG passage I have the problem with is: > > > > D) When searching for a matching TCB upon reception of an INIT > > or INIT-ACK chunk the receiver SHOULD use not only the > > source address of the packet (containing the INIT or > > INIT-ACK) but the receiver SHOULD also use all valid > > address parameters contained within the chunk. > > > >I don't need to use the source address list within the INIT-ACK > >chunk to find the proper TCB above. I only need the source address > >of the packet: quite the opposite of what this IG passage claims. > > > > > > You are 100% wrong.. if you sent the INIT to IP-A and the source address > is IP-B how will you find the TCB.. your implementation does ONLY > because you pre-listed IP-B in the TCB of the sender of the INIT.. this is > ok to do (that is why the SHOULD is there and NOT a MUST). But for > MOST implementations that are general.. obviously NOT yours.. you > must go through the INIT-ACK to find the TCB... I use VT. I don't use a pre-determined address list. > > How much clearer do you need Ivan, Caitlin and I to be.. we all understand > this.. you seem not to since all you can see is your very very limited > implementation that places requirements on the user to pre-know > all addresses of the peer.. sorry this is ok for the SS7 world.. but it > is NOT ok for a general stack... I use VT. I don't use a pre-determined address list. I don't need to look in the source address list. > > Expect the language to stay in... you are alone in your objections... It is just a draft, so the recommendations don't count for anything yet. > > > > > > >>I think this is Caitlin's point.. you must clean up this > >>extra TCB... and you do that by looking at the peers address > >>list and making sure you don't have a seperate TCB hanging > >>around... You have just shown one example of looking at > >>the address list in the INIT-ACK. > >> > >> > > > >How the implementation cleans up extra TCBs is its own business and > >has no bearing on the passage in the IG. The passage says "When > >searching for a matching TCB". > > > >I don't see anywhere here where it is necessary to analyze the source > >address list in the INIT-ACK "[w]hen searching for a matching TCB." > >Could you modify the example to show such a case as stated in IG 2.18.2? > > > > > > My previous email to you showed you such a case.. and you ignored it.. this > email shows the very same case.. and you ignore it.. Your previous mail shows the opposite: as you said in that: the TCB can be found by VT and looking in the source address list is not necessary. > > The ONLY reason your implementation works is because you require > the user to preset all of the peers addresses in before sending an INIT.. > Its ok to do, thats why the passage is a SHOULD.. the rest of us > who are developing general purpose stacks that will make there way > into a lot of varied products can NOT work in such a narrow way.. That has nothing to do with the examples we are dicussing. When our implementation knows the addresses of the peer, the second INIT would never even be launched. When it does not, it relies on VT to find the TCB and doesn't need the addresses in the address list to do so. > > You are very much alone in your objections...Bottom line.. > the passage remains as is..... I understand that the IG will never make it past draft anyway, so it doesn't really matter if it is just your personal view... --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Mar 3 18:55:27 2003 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18644 for ; Mon, 3 Mar 2003 18:55:26 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h23NipP7023585 for ; Mon, 3 Mar 2003 15:44:51 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h23Nj5Or001869 for ; Mon, 3 Mar 2003 15:45:06 -0800 (PST) Received: from gw.openss7.com (IDENT:n1p03tWSuuzcgSFV5DyftqCEoHERyFed@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h23NjICZ025305 for ; Mon, 3 Mar 2003 15:45:20 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:xqD5W3q58aAzaxXRKS7z6btboEBsABwD@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h23NdgD24573; Mon, 3 Mar 2003 16:39:42 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h23Ndgv25657; Mon, 3 Mar 2003 16:39:42 -0700 Date: Mon, 3 Mar 2003 16:39:42 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303163942.O16782@openss7.org> Reply-To: bidulock@openss7.org References: <3E63ABB1.2030201@cisco.com> <20030303130344.G16782@openss7.org> <3E63BB2B.1080504@cisco.com> <20030303153921.K16782@openss7.org> <3E63DEB5.9000102@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E63DEB5.9000102@cisco.com>; from rrs@cisco.com on Mon, Mar 03, 2003 at 05:01:09PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > >> > >> > > > >Well, the answer to Vijay's question (that started this thread) is: > > > > 1) Yes, you can ignore the source address list when searching for the > > TCB contrary to IG 2.18 if you have other mechanisms (e.g. unique > > VT generation and lookup, pre-known source addresses, or any number > > > > ^^^^^^^^^^^^^^^^^^^^^^ > > and here is the relevant > thing you MUST do in conjunction with > Brian's method for this... > > > of other techniques) to find the appropriate TCB. > > > > 2) Nothing bad will happen if you don't look in the source address list > > if you otherwise meet the requirements of RFC 2960. > > > > Except you won't have a general purpose stack that can be used except in > a very very > limited way.. Wrong. VT lookup is completely general. There is no question that one needs to find the TCB, it is just not necessary to use the source address list to do so. VT lookup will do. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Mar 3 19:36:15 2003 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19405 for ; Mon, 3 Mar 2003 19:36:14 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h240TYP7015749; Mon, 3 Mar 2003 16:29:34 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEA69410; Mon, 3 Mar 2003 16:29:48 -0800 (PST) Message-ID: <3E63F37B.7040500@cisco.com> Date: Mon, 03 Mar 2003 18:29:47 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030303135341.I16782@openss7.org> <3E63C6FF.9040104@cisco.com> <20030303151206.J16782@openss7.org> <3E63DE21.3080304@cisco.com> <20030303163628.N16782@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian > > >>You are very much alone in your objections...Bottom line.. >>the passage remains as is..... >> >> > >I understand that the IG will never make it past draft anyway, so it >doesn't really matter if it is just your personal view... > > > Everyone but you seems to understand the concept.. it is not my personal view... you are the one who seems to have a personal view.. And you are most likely correct the IG will most likely not go past draft but be rolled together with 2960 and 3309 into a new RFC... hopefully DS... R > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Mar 3 20:01:25 2003 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19831 for ; Mon, 3 Mar 2003 20:01:19 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h240t86N028543 for ; Mon, 3 Mar 2003 16:55:08 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h240t7HA005427 for ; Mon, 3 Mar 2003 16:55:07 -0800 (PST) Received: from gw.openss7.com (IDENT:YNjA7eyhFYcHc1VJbVPUHx3Dffm7cO5m@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h240qJrO027649 for ; Mon, 3 Mar 2003 16:52:21 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:8CEy9hrxbR4mVRVghnA925GDLLyaNTcE@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h240o8D25623; Mon, 3 Mar 2003 17:50:08 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h240o8x27584; Mon, 3 Mar 2003 17:50:08 -0700 Date: Mon, 3 Mar 2003 17:50:07 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303175007.A26066@openss7.org> Reply-To: bidulock@openss7.org References: <20030303135341.I16782@openss7.org> <3E63C6FF.9040104@cisco.com> <20030303151206.J16782@openss7.org> <3E63DE21.3080304@cisco.com> <20030303163628.N16782@openss7.org> <3E63F37B.7040500@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E63F37B.7040500@cisco.com>; from rrs@cisco.com on Mon, Mar 03, 2003 at 06:29:47PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > Brian > > > > > > >>You are very much alone in your objections...Bottom line.. > >>the passage remains as is..... > >> > >> > > > >I understand that the IG will never make it past draft anyway, so it > >doesn't really matter if it is just your personal view... > > > > > > > Everyone but you seems to understand the concept.. it is not > my personal view... you are the one who seems to have > a personal view.. > > > And you are most likely correct the IG will most likely not > go past draft but be rolled together with 2960 and 3309 into > a new RFC... hopefully DS... Then we can pick this up again at LC. I'm pretty sure in that process that RFC 2119 will be respected and the SHOULD dropped. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Mar 3 21:33:10 2003 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21486 for ; Mon, 3 Mar 2003 21:33:08 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h242R456029682; Mon, 3 Mar 2003 18:27:04 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEA84631; Mon, 3 Mar 2003 18:27:02 -0800 (PST) Message-ID: <3E640EF5.7020108@cisco.com> Date: Mon, 03 Mar 2003 20:27:02 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030303135341.I16782@openss7.org> <3E63C6FF.9040104@cisco.com> <20030303151206.J16782@openss7.org> <3E63DE21.3080304@cisco.com> <20030303163628.N16782@openss7.org> <3E63F37B.7040500@cisco.com> <20030303175007.A26066@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian >> >> >> >>> >>> >>> >>> >>>>You are very much alone in your objections...Bottom line.. >>>>the passage remains as is..... >>>> >>>> >>>> >>>> >>>I understand that the IG will never make it past draft anyway, so it >>>doesn't really matter if it is just your personal view... >>> >>> >>> >>> >>> >>Everyone but you seems to understand the concept.. it is not >>my personal view... you are the one who seems to have >>a personal view.. >> >> >>And you are most likely correct the IG will most likely not >>go past draft but be rolled together with 2960 and 3309 into >>a new RFC... hopefully DS... >> >> > >Then we can pick this up again at LC. I'm pretty sure in that >process that RFC 2119 will be respected and the SHOULD dropped > I doubt it for at least three reasons (I am sure there will be others by the time we go to LC): 1) By using the Vtags for a hash lookup you have serverly compromised the security associated with them. I have spent a bit more time reviewing your code.. and basically anytime the source port and Vtag match you ship the packet up the stream to the processing layer of your SCTP stack. This means that if I know a port that you are likely to have a listener , say for example we are using SCTP for http.. not to far fetched.. and I know there will be quite some number of connections (invision CNN or google)... then instead of having a 1 in 4 billion chance of guessing a Vtag.. I now have a N in 4 billion chance (where N is the number of connections you have up right now) and even more so I don't even need to know a source address and port you think are valid.. you don't care.. you will accept any as long as the V-tag and destination port are correct. This is an extreme mis-use of a security feature that works to compromise the security put into the protocol.. I doubt that the IESG would support such mis-use of a feature in the protocol. 2) Your code, looking back at Caitlins example... as near as I can tell would create both associations.. due to your blind faith in the vtag and the destination port... each INIT-ACK would find the sp that sent out the INIT and there is no cross validation.. you would end up with two associations .. as Caitlin surmised.. in violation of the RFC... 3) It is always possible to generate two random numbers that are the same.. this is what random numbers are.. truely random.. so you always have the chance of generating two tags into INIT-ACK's that are the same.. thus making one of the associations fail to come up.. I doubt the IESG likes blackholes in protocols left lying around... In fact, it may well be the IESG would want us to strengthen the SHOULD to a MUST... to help prevent 1 and possibly 3... R > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Mar 4 01:44:31 2003 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26381 for ; Tue, 4 Mar 2003 01:44:29 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h246asP7012225 for ; Mon, 3 Mar 2003 22:36:54 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h246b8un010077 for ; Mon, 3 Mar 2003 22:37:09 -0800 (PST) Received: from gw.openss7.com (IDENT:dpE1QjNUgNEXwePToqrS9hGOeAeV9Sij@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h246ZJrO016662 for ; Mon, 3 Mar 2003 22:35:19 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:LaP0eQiBq4LSUXPz4SJ+oyJelBtBADQL@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h246W4D30620; Mon, 3 Mar 2003 23:32:04 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h246W3J00872; Mon, 3 Mar 2003 23:32:03 -0700 Date: Mon, 3 Mar 2003 23:32:03 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030303233203.B32643@openss7.org> Reply-To: bidulock@openss7.org References: <20030303135341.I16782@openss7.org> <3E63C6FF.9040104@cisco.com> <20030303151206.J16782@openss7.org> <3E63DE21.3080304@cisco.com> <20030303163628.N16782@openss7.org> <3E63F37B.7040500@cisco.com> <20030303175007.A26066@openss7.org> <3E640EF5.7020108@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E640EF5.7020108@cisco.com>; from rrs@cisco.com on Mon, Mar 03, 2003 at 08:27:02PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >Randall, > > > >On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > > > > > > > >>Brian > >> > >> > >> > >>> > >>> > >>> > >>> > >>>>You are very much alone in your objections...Bottom line.. > >>>>the passage remains as is..... > >>>> > >>>> > >>>> > >>>> > >>>I understand that the IG will never make it past draft anyway, so it > >>>doesn't really matter if it is just your personal view... > >>> > >>> > >>> > >>> > >>> > >>Everyone but you seems to understand the concept.. it is not > >>my personal view... you are the one who seems to have > >>a personal view.. > >> > >> > >>And you are most likely correct the IG will most likely not > >>go past draft but be rolled together with 2960 and 3309 into > >>a new RFC... hopefully DS... > >> > >> > > > >Then we can pick this up again at LC. I'm pretty sure in that > >process that RFC 2119 will be respected and the SHOULD dropped > > > > > I doubt it for at least three reasons (I am sure there will be > others by the time we go to LC): > > 1) By using the Vtags for a hash lookup you have serverly compromised > the security associated with them. I have spent a bit more time > reviewing > your code.. and basically anytime the source port and Vtag match > you ship the packet up the stream to the processing layer of your SCTP > stack. This means that if I know a port that you are likely to have a > listener , say for example we are using SCTP for http.. not to far > fetched.. and I know there will be quite some number of connections > (invision CNN or google)... then instead of having a 1 in 4 billion > chance of guessing a Vtag.. I now have a N in 4 billion chance > (where N is the number of connections you have up right now) and > even more so I don't even need to know a source address and > port you think are valid.. you don't care.. you will accept any as > long as the V-tag and destination port are correct. This is an extreme > mis-use of a security feature that works to compromise the > security put into the protocol.. I doubt that the IESG would support > such mis-use of a feature in the protocol. IP addresses are trivial to spoof. There is no security afforded in addition to the VT by adding spoofable IP addresses to the match. If you need security, I suggest you (re)read the security section of RFC 2960. ;) > > 2) Your code, looking back at Caitlins example... as near as I can tell > would create both associations.. due to your blind faith in the vtag > and the destination port... each INIT-ACK would find the sp that > sent out the INIT and there is no cross validation.. you would > end up with two associations .. as Caitlin surmised.. in violation of > the RFC... Two associations will only be set up if the peer violates the RFC first and allows both COOKIE-ECHO's to establish an association. If you look at the COOKIE-ECHO handling you will see that our implementation will not set up both associations even if it could be persuaded to launch the two inits of Caitlin's example. This is because any second COOKIE-ECHO is discarded per the default case in RFC 2960 5.2.4 (no tie tags, mismatch on both local and peer tag). Nowhere in the RFC does it say that it is illegal to launch two COOKIE-ECHOs for two different associations for the same set of endpoints. It is illegal to _establish_ two associations between the set of end-points. The receiver of two COOKIE-ECHOs must only move one association to the ESTABLISHED state or it is in violation of the MUST in the RFC. Our current implementation launches two COOKE-ECHO's in Caitlin's example, but it is not necessary to do so. This is what I was trying to tell you in the detailed example. The source address of the packet (combined with destination address and port pair) on the second INIT-ACK is sufficient to find the first expanded TCB (again without looking in the source address list). For INIT-ACKs all we would have to do is call and fail an sctp_lookup_tcb before calling sctp_lookup_vtag (1 line of code). I think that would be a waste for a corner case when the peer must refuse the second COOKIE-ECHO. Long hard lookup with locks held on the hashes does not scale. Particularly when the more exhaustive search is almost never necessary. We should put it inside the CONFIG_SCTP_SLOW_VERIFICATION ifdef so those that want poor performance can get what they ask for. > > 3) It is always possible to generate two random numbers that are the > same.. this is what random numbers are.. truely random.. so you > always have the chance of generating two tags into INIT-ACK's that > are the same.. thus making one of the associations fail to come up.. I > doubt the IESG likes blackholes in protocols left lying around... The VTAG generation algorithm is pseudo random with a random seed and an occassional random swirl. Such series are far less likely to repeat than total random functions. There are other more likely events that will interfere with association initialization (e.g. noise). It I really thought it was important, I would check for duplicates in the vtag hash while entering the TCB into the vtag hash and reselect the vtag if a match was found. This is rather simple to include because the socket/stream is placed in the vtag hash before any message with the vtag is launched. 3 or 4 lines of code would do it. Thanks for the suggestion for improvement. I could put the little loop in sctp_get_vtag to check the hash before returning the tag. Then it will be guaranteed that there are no duplicates in the hash. As the lookup is just a normal hash lookup on the vtag to see if it exists first, there should be no problem with scaling. This one could go in the CONFIG_SCTP_SLOW_VERIFICATION ifndef. > In fact, it may well be the IESG would want us to strengthen the SHOULD > to a MUST... to help prevent 1 and possibly 3... This is much like telling someone how they SHOULD or MUST move bytes around when calculating an CRC. You didn't agree with me on that one either... ...but it changed. Thanks for the inspection of the code. We now have two relatively minor improvements and still don't have to look in the INIT or INIT-ACK source address lists. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Mar 4 11:17:58 2003 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29055 for ; Tue, 4 Mar 2003 11:17:56 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h24GB056029718 for ; Tue, 4 Mar 2003 08:11:00 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h24GAxgc027074 for ; Tue, 4 Mar 2003 08:10:59 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h24G8FbS019288 for ; Tue, 4 Mar 2003 08:08:23 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24FoiF21284 for ; Tue, 4 Mar 2003 17:50:44 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Mar 2003 17:47:28 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Mar 2003 17:47:27 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Mar 2003 17:47:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: Matching addresses in INIT and INIT ACK Date: Tue, 4 Mar 2003 17:47:26 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLhxfojxnluRjVgTGC/w4YryIGvcAAkur/g From: To: , , , X-OriginalArrivalTime: 04 Mar 2003 15:47:27.0696 (UTC) FILETIME=[5BA5C500:01C2E265] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA29055 Hi! So this is the example of INIT collision. It is the typical one, when both peers start about at the same time. This is the notation used: - For all the chunks: o In capital letters the NAME OF CHUNK. o VT is the Verification Tag included in the SCTP header. o Source Address:Port->Destination Address:Port. - For INIT and INIT ACK: o IT is the Initiation Tag included in the header of the chunk. - For INIT ACK and COOKIE ECHO: o VTloc and VTpeer are the values of the local Verification Tag (the one the INIT ACK sender expects in the SCTP headers of the peer) and the peer's Verification Tag (the one the INIT ACK senders includes in its SCTP headers) as included in the State Cookie. Note that those values are directly copied from the INIT ACK and included in the COOKIE ECHO. o TTloc and TTpeer are the values of the local Tie Tag (the value of VTloc at the moment of sending the INIT ACK) and the peer's Tie Tag (the value of VTpeer at the moment of sending the INIT ACK) as included in the State Cookie. Note that those values are directly copied from the INIT ACK and included in the COOKIE ECHO. The TCBs are only shown when there is a change. They show: - Source address/es:Source Port. - Destination address/es: Destination Port. - Local Verification Tag. - Peers Verification Tag. - State. Let's see the scenario. Host A Host B/C TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB A:1000 \ A:1000->B:1000 ?:1000->A:1000 / B,C:1000 B:1000 \ / A:1000 VTloc:W \ / VTloc:X VTpeer:0 \ / VTpeer:0 C-WAIT \ / C-WAIT \--------------------\ /--------------------/ \/ /\ / \ (1) <-------------------------/ \-------------------------> \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:X / \ A:1000->C:1000 B:1000->A:1000 / \ VTloc:Y VTpeer:X VTloc:X VTpeer:W / \TTloc:0 TTpeer:0 TTloc:X TTpeer:0/ \ / \ / \--------------------\ /--------------------/ \/ /\ / \ <-------------------------/ \-------------------------> TCB \ COOKIE ECHO VT:X COOKIE ECHO VT:Y / TCB A:1000 \ A:1000->B:1000 C:1000->A:1000 / B,C:1000 B,C:1000 \ VTloc:X VTpeer:W VTloc:Y VTpeer:W / A:1000 VTloc:W \TTloc:X TTpeer:0 TTloc:0 TTpeer:0/ VTloc:X VTpeer:X \ / VTpeer:Y C-ECHOED \ / C-ECHOED \--------------------\ /--------------------/ \/ /\ / \ (2) X<-------------------------/ \-------------------------> (3) COOKIE ACK VT:W / TCB / B,C:1000 / A:1000 / VTloc:X / VTpeer:W / ESTABLISH /--------------------/ / / / (4) X<-------------------------/ Some remarks: (1) At this point, Host A doesn't recognize the INIT as coming from the same association it is trying to establish. The VT is completely different. Thus, it goes in the normal (and wrong) establishment procedure, creates a new IT and set the Tie Tags to 0. (2) The received COOKIE ECHO is discarded, since the VT is wrong (Host A is expecting VT set to W). (3) Host B,C recognizes the collision due to the Tie Tags, recognize it as situation B of section 5.2.4 and updates the VTpeer to W. (4) The COOKIE ACK is discarded, since Host A is in the C-ECHOED state. And now? Host A will retransmit the COOKIE ECHO, Host B,C will answer again, and the COOKIE ACK is discarded again. Conclusion: Host A cannot establish an association with Host B,C in this situation. Brian, did I make any mistake? I hope I didn't... :-/ BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Mar 4 14:06:46 2003 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05790 for ; Tue, 4 Mar 2003 14:06:45 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h24Ivu56007960 for ; Tue, 4 Mar 2003 10:57:56 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h24Ivtdj008341 for ; Tue, 4 Mar 2003 10:57:55 -0800 (PST) Received: from thebe.your-site.com (ns5.your-site.com [140.186.45.30] (may be forged)) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h24IsPbS003705 for ; Tue, 4 Mar 2003 10:54:46 -0800 (PST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 5E0C424514D for ; Tue, 4 Mar 2003 13:53:04 -0500 (EST) Date: Tue, 4 Mar 2003 12:54:50 -0600 From: Caitlin Bestler Subject: RE: Address Matching in INIT-ACK/COOKIE-ECHO To: sctp-impl@external.cisco.com X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit For the record, an example that shows that the address list within an INIT-ACK must eventually be examined. There are two multihomed hosts, neither of which is aware that the other is multi-homed. The active host uses addresses A and B, the passive host uses addresses X and Y. While X and Y are both reachable via either of AB's interfaces, the default route to X uses the interface where the source address should be A while for Y the default route implies use of source address B. The scenario: INIT - From A:1000 to X:1000 Address List: A,B Initiation Tag: I INIT - From B:1000 to Y:1000 Address List: A,B Initiation Tag: J INIT-ACK - From X:1000 to A:1000 Address List: X,Y Verification Tag: I COOKIE-ECHO - From X:1000 to A:1000 Verificatin Tag: I INIT-ACK - From Y:1000 to B:1000 Address List: X,Y Verification Tag: J COOKIE-ECHO - From Y:1000 to B:1000 Verificatin Tag: J If neither side examines the Address List, the passive side will firmly establish two associations with the same endpoints. Checks based solely upon IP header information and tags will not differentiate either the INIT-ACKs or the COOKIE-ECHOes. They cannot, without looking at the lists, all of the packet would look identical to the packets expected if the other side were truly two different hosts. The only way to avoid RFC-violating duplicate associations is to examine the address list at some point. It should be obvious that this check should be done at the first opportunity (on receipt of the INIT-ACK). Caitlin Bestler http://asomi.com/CaitlinBestler/ From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Mar 4 14:35:47 2003 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06841 for ; Tue, 4 Mar 2003 14:35:45 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h24JR66N013139 for ; Tue, 4 Mar 2003 11:27:06 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h24JR5tP003850 for ; Tue, 4 Mar 2003 11:27:05 -0800 (PST) Received: from gw.openss7.com (IDENT:tBFICR9RHORZZCHobGwXVUskZR/cjFsn@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h24JQjrG001449 for ; Tue, 4 Mar 2003 11:26:49 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:QMikPR3hy1Zsu8TJVSz5uvebwpzmfFh5@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h24JMUD10994; Tue, 4 Mar 2003 12:22:30 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h24JMUN15695; Tue, 4 Mar 2003 12:22:30 -0700 Date: Tue, 4 Mar 2003 12:22:30 -0700 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: sctp-impl@external.cisco.com Subject: Re: Address Matching in INIT-ACK/COOKIE-ECHO Message-ID: <20030304122230.A15492@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Tue, Mar 04, 2003 at 12:54:50PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Caitlin, On Tue, 04 Mar 2003, Caitlin Bestler wrote: > For the record, an example that shows that the address list > within an INIT-ACK must eventually be examined. > > There are two multihomed hosts, neither of which is aware > that the other is multi-homed. The active host uses > addresses A and B, the passive host uses addresses X and Y. > > While X and Y are both reachable via either of AB's > interfaces, the default route to X uses the interface > where the source address should be A while for Y the > default route implies use of source address B. > > > The scenario: > > INIT - From A:1000 to X:1000 > Address List: A,B > Initiation Tag: I > > INIT - From B:1000 to Y:1000 > Address List: A,B > Initiation Tag: J > > INIT-ACK - From X:1000 to A:1000 > Address List: X,Y > Verification Tag: I > > COOKIE-ECHO - From X:1000 to A:1000 > Verificatin Tag: I > > INIT-ACK - From Y:1000 to B:1000 > Address List: X,Y > Verification Tag: J > > COOKIE-ECHO - From Y:1000 to B:1000 > Verificatin Tag: J > > > > If neither side examines the Address List, the passive The address list does not need to be examined. The the first INIT-ACK in these examples always expands the TCB. The TCB in the second INIT-ACK above can be found using the source address of the INIT-ACK packet (Y) and does not require looking in the address list at all "[w]hen searching for the TCB", contrary to IG section 2.18. > side will firmly establish two associations with the > same endpoints. Checks based solely upon IP header > information and tags will not differentiate either > the INIT-ACKs or the COOKIE-ECHOes. They cannot, without > looking at the lists, all of the packet would look identical > to the packets expected if the other side were truly two > different hosts. > > The only way to avoid RFC-violating duplicate associations > is to examine the address list at some point. But not "[w]hen searching for the TCB" as the IG mis-states. --brian > It should be > obvious that this check should be done at the first > opportunity (on receipt of the INIT-ACK). > > > > > > > > > > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Tue Mar 4 15:05:16 2003 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07810 for ; Tue, 4 Mar 2003 15:05:14 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h24K00HK025490 for ; Tue, 4 Mar 2003 12:00:00 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h24K0KhT001239 for ; Tue, 4 Mar 2003 12:00:20 -0800 (PST) Received: from gw.openss7.com (IDENT:OHk6RMifyK/hUSK67v5LQ3+UPt4R51YB@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h24JvmbS028967 for ; Tue, 4 Mar 2003 11:57:59 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:vOVFKEq8P44S7jTKkJ332KFi3ONtOczY@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h24JtJD11478; Tue, 4 Mar 2003 12:55:19 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h24JtIY16277; Tue, 4 Mar 2003 12:55:18 -0700 Date: Tue, 4 Mar 2003 12:55:18 -0700 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030304125518.A14773@openss7.org> Reply-To: bidulock@openss7.org References: <20030303233203.B32643@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Tue, Mar 04, 2003 at 09:13:41AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Caitlin, On Tue, 04 Mar 2003, Caitlin Bestler wrote: > Brian, > > You are correct on two fronts: > > a) The two associations will merge by the time > the extra COOKIE-ECHO is received. > > b) It is possible to generate unique VTAGs. Simply > using the TCB's address would be one method. Unfortunately a VT must be generated in response to an INIT without creating a TCB. Also, addresses are not a secure way of creating a VT, because they are too predictable for a given architecture. > > What you haven't answered is why it should be acceptable > to subject the network to the excess COOKIE-ECHO messages. > There is at least one, and likely more if the eclipsed > association continues to retransmit. It is not necessary to send the second COOKIE-ECHO. I have already provided this for you in example. > > It is clearly appropriate to tell implementers that they > SHOULD NOT put spurious messages onto the net. It is not necessary to look in the source address list to not send the second COOKIE-ECHO. Look at the detailed diagrams I sent: it is always sufficient to use the address pair and port pair from the IP and SCTP header to find the "expanded" TCB from the first INIT-ACK. So don't tell implementors that they SHOULD be doing something that they simply don't have to. If you would like to say: Implementations SHOULD NOT generate excess packets, go ahead. But don't tell the implementation how it SHOULD go about doing that unless it is important to interoperability and not just performance. > > I'll concede that there are environments where this is > sufficiently low probability that an argument can be made > against telling them that they MUST NOT do so. Any system > that is or uses a service for the Internet as a whole (such > as an SCTP web server) is clearly not one of them. But a > closed set of servers that already have their own methods > of authentication at the ULP level probably could be allowed > to skip the test (although I remain unconvinced that it > really is much of a benefit). The test recommended is not necessary to get rid of the COOKIE-ECHO. Proper application of SO_REUSEADDR on a socket interface gets rid of your example, but the way. Unless the user forces SO_REUSEADDR on both sockets, the bind of the second socket to A:1000 will fail with EADDRBUSY. So the sockets interface has to be forced to get it to do what you show in the first place. This is because it is almost never what the user wants: to bind two sockets to the same static port and address (not listening). Your example is simply a further misconfiguration and would only result from misconfigured or broken software. (Broken and misconfigured application software can cause more waste in the network than the occasional seemingly redundant COOKIE-ECHO). > > I also remain skeptical that deferring detection until > COOKIE-ECHO processing will properly handle all of the > "wrong state" COOKIE-ECHO scenarios. In particular, how > does the passive side distinquish between repeat > COOKIE-ECHOes from the eclipsed association and a peer > restart? It cannot tell, now can it? This is why SO_REUSADDR defaults to don't reuse and separate sockets cannot bind to the same statically assign port and address (necessary to launch the inits in your example). TCP cannot detect the difference between a SYN on a half-open socket and a second SYN from a different socket for the same address either. What were you going to do? Refuse to send the second COOKIE-ECHO and pass an error to the user? What if the peer application refuses (aborts) the first connection instead of accepting it? As follows: INIT (A->B) -------------------------------------------------------> INIT (A->C) -------------------------------------------------------> (B/C->A) INIT-ACK <------------------------------------------------------- COOKIE-ECHO (For first INIT) -------------------------------------------------------> (Indication to ULP) (B/C->A) INIT-ACK <------------------------------------------------------- Abort to user. ABORT <------------------------------------------------------- (User refuses connection A->B) Not on sockets, but with the STREAMS interface it is possible to refuse connection indications before they are accepted. If the ULP is configured to accept A->C initiated connections but refuse (ABORT before COOKIE-ACK) A->B initiated connections, and the Host A is going to always attempt A->B before A->C, then this will hang in a loop forever, generating many useless packets in the network. Just because you send a COOKIE-ECHO does not mean that the association will be accepted and a COOKIE-ACK received. This is what I meant by predicting the future. The peer (and the peer ULP) should be given the oppotunity to choose which connection it wishes to accept and which it wishes to refuse. The user cannot be given an opportunity to decide on the INIT for obvious reasons. Also, what if the local user aborts on the connection confirmation? INIT (A->B) -------------------------------------------------------> INIT (A->C) -------------------------------------------------------> (B/C->A) INIT-ACK <------------------------------------------------------- (Confirmation to ULP) (B/C->A) INIT-ACK <------------------------------------------------------- Abort to user. ------> ULP aborts first connection. Above are two examples that result in no assocation (bad thing) when if both COOKIE-ECHOs were sent would result in one association. Remember that all sockets implementations of TCP strongly discourage the equivalent from happening in TCP by forcing the user to use the SO_REUSEDADDR flag on all binds to the port and warning that the use of SO_REUSEADDR has potential negative effects on the network and robustness of the protocol. I was told on TSVWG not long ago that there are _no_ useful applications that statically assign both port numbers. The Internet does not do this. So, regardless of Randall's claims about "general purpose" stacks, the Internet is not "general purpose". It is client/server where the client always dynamically assigns its port number. Your example will not happen on the Internet, only in highly specialized applications that should know what they are doing. SO_REUSEADDR will keep casual users from stumbingling into this scenario (second static port bind will fail). Efficiencies including a tradeoff of performance is not a question of interoperability, it is an implementation decision. The keywoard SHOULD "MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability." I can assure you that the SHOULD of IG section 2.18 will never make it into an RFC. It says how one SHOULD _search_for_something_. It is IMO a clear and obvious violation of the "MUST" in RFC 2119 regarding use of keywords. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Mar 4 15:26:54 2003 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09175 for ; Tue, 4 Mar 2003 15:26:52 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h24KNoP7018154 for ; Tue, 4 Mar 2003 12:23:50 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h24KO43v022492 for ; Tue, 4 Mar 2003 12:24:04 -0800 (PST) Received: from gw.openss7.com (IDENT:372YlbO4kgsdvLZRwHulnIw+armeixO0@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h24KNv1S011636 for ; Tue, 4 Mar 2003 12:24:03 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:VIBTtTpflQiCS/LvOy0dyKKJIZeKA6XR@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h24KJ4D11962; Tue, 4 Mar 2003 13:19:04 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h24KJ3I16946; Tue, 4 Mar 2003 13:19:03 -0700 Date: Tue, 4 Mar 2003 13:19:03 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: rrs@cisco.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030304131903.B15492@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Tue, Mar 04, 2003 at 05:47:26PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Tue, 04 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Hi! > > So this is the example of INIT collision. It is the typical one, when > both peers start about at the same time. This is the notation used: > > - For all the chunks: > o In capital letters the NAME OF CHUNK. > o VT is the Verification Tag included in the SCTP header. > o Source Address:Port->Destination Address:Port. > > - For INIT and INIT ACK: > o IT is the Initiation Tag included in the header of the chunk. > > - For INIT ACK and COOKIE ECHO: > o VTloc and VTpeer are the values of the local Verification > Tag (the one the INIT ACK sender expects in the SCTP headers > of the peer) and the peer's Verification Tag (the one the INIT > ACK senders includes in its SCTP headers) as included in the > State Cookie. Note that those values are directly copied from > the INIT ACK and included in the COOKIE ECHO. > o TTloc and TTpeer are the values of the local Tie Tag (the > value of VTloc at the moment of sending the INIT ACK) and the > peer's Tie Tag (the value of VTpeer at the moment of sending > the INIT ACK) as included in the State Cookie. Note that those > values are directly copied from the INIT ACK and included in > the COOKIE ECHO. > > The TCBs are only shown when there is a change. They show: > - Source address/es:Source Port. > - Destination address/es: Destination Port. > - Local Verification Tag. > - Peers Verification Tag. > - State. > > Let's see the scenario. > > > Host A Host B/C > > TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB > A:1000 \ A:1000->B:1000 ?:1000->A:1000 / B,C:1000 > B:1000 \ / A:1000 > VTloc:W \ / VTloc:X > VTpeer:0 \ / VTpeer:0 > C-WAIT \ / C-WAIT > \--------------------\ /--------------------/ > \/ > /\ > / \ > (1) <-------------------------/ \-------------------------> > > \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:X / > \ A:1000->C:1000 B:1000->A:1000 / > \ VTloc:Y VTpeer:X VTloc:X VTpeer:W / > \TTloc:0 TTpeer:0 TTloc:X TTpeer:0/ > \ / > \ / > \--------------------\ /--------------------/ > \/ > /\ > / \ > <-------------------------/ \-------------------------> > > TCB \ COOKIE ECHO VT:X COOKIE ECHO VT:Y / TCB > A:1000 \ A:1000->B:1000 C:1000->A:1000 / B,C:1000 > B,C:1000 \ VTloc:X VTpeer:W VTloc:Y VTpeer:W / A:1000 > VTloc:W \TTloc:X TTpeer:0 TTloc:0 TTpeer:0/ VTloc:X > VTpeer:X \ / VTpeer:Y > C-ECHOED \ / C-ECHOED > \--------------------\ /--------------------/ > \/ > /\ > / \ > (2) X<-------------------------/ \-------------------------> (3) > > COOKIE ACK VT:W / TCB > / B,C:1000 > / A:1000 > / VTloc:X > / VTpeer:W > / ESTABLISH > /--------------------/ > / > / > / > (4) X<-------------------------/ > > > > Some remarks: > > (1) At this point, Host A doesn't recognize the INIT as coming from > the same association it is trying to establish. The VT is completely > different. Thus, it goes in the normal (and wrong) establishment > procedure, creates a new IT and set the Tie Tags to 0. > > (2) The received COOKIE ECHO is discarded, since the VT is wrong (Host > A is expecting VT set to W). > > (3) Host B,C recognizes the collision due to the Tie Tags, recognize > it as situation B of section 5.2.4 and updates the VTpeer to W. > > (4) The COOKIE ACK is discarded, since Host A is in the C-ECHOED state. > > > And now? > > Host A will retransmit the COOKIE ECHO, Host B,C will answer again, > and the COOKIE ACK is discarded again. > > Conclusion: Host A cannot establish an association with Host B,C in > this situation. > > Brian, did I make any mistake? I hope I didn't... :-/ In both our STREAMS and Sockets implementations you cannot bind to a static port when another STREAM/Socket is bound to that port as a listener. That's just how STREAMS/Socket semantics work. If Host A is our implementation, the INIT from Host B/C for A:1000 will be refused because there is no STREAM/Socket listening on that port and only one association will form. If Host B/C is our implemenataion, the INIT from Host A for B/C:1000 will be refused because there is no listening socket. This is no different in TCP/Sockets. TCP sockets do not allow you to bind to a static port and address if there is a socket listening on that port. You cannot even make two TCP sockets implementations do what you describe here. Because our implementation follows standard XTI/XNS and Sockets semantics at most one association will form and there will be none of the problems you describe. You seem to focus on collisions (which are not possible using Sockets) and Caitlin focusses on two ULPs launching from the same static address (which is heavily discouraged in Sockets with SO_REUSEADDR and is not possible unless the flag is set on ALL sockets using the address and NO listening sockets). You both dig down into the little unused corner case of static port assignment to justify a SHOULD on "how to search"? --brian > > BR Iván Arias Rodríguez -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-2.cisco.com Wed Mar 5 09:49:50 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02021 for ; Wed, 5 Mar 2003 09:49:49 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h25EXJ3D009461; Wed, 5 Mar 2003 06:33:20 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEC83458; Wed, 5 Mar 2003 06:33:18 -0800 (PST) Message-ID: <3E660AAE.9000108@cisco.com> Date: Wed, 05 Mar 2003 08:33:18 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sctp-impl@external.cisco.com CC: Marko Lindholm , "Michael Tuexen (at home)" , "Michael Tuexen (at work)" Subject: SCTP Patch Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi: We once again have a new patch level for the BSD release patch number 6 is now available on: http://www.sctp.org You will find a few additional bug fixes reported by Michael Tuexen on the socket api. Also Marko Lindholm found a issue with TTL setting. The rest is once again patches of the two previous patches that will go with the current snap of kame 20030303.. Thanks R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Wed Mar 5 15:51:48 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27786 for ; Wed, 5 Mar 2003 15:51:47 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25KlQv2005709 for ; Wed, 5 Mar 2003 12:47:26 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h25KklYg004612 for ; Wed, 5 Mar 2003 12:46:47 -0800 (PST) Received: from thebe.your-site.com (lists.your-site.com [140.186.45.30]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h25KlQ1S012152 for ; Wed, 5 Mar 2003 12:47:32 -0800 (PST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 7D04F24487A for ; Wed, 5 Mar 2003 15:43:11 -0500 (EST) Date: Wed, 5 Mar 2003 14:44:42 -0600 From: Caitlin Bestler Subject: Address List Change on Restart To: sctp-impl@external.cisco.com X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Section 10.1 (Interface with Upper Layer - ULP-to-SCTP) specifies: o local eligible address list - An address list that the local SCTP endpoint should bind. By default, if an address list is not included, all IP addresses assigned to the host should be used by the local endpoint. When this default is being reused, it is highly plausible that a restart would result in the list of IP addresses being different than previously. If such a system attempts to restart an association immediately. Is the peer required to note the changes in the address list during the peer restart sequence specified for case A (peer restart) in section 5.4.2 ("Handle a COOKIE ECHO when a TCB exists")? Caitlin Bestler http://asomi.com/CaitlinBestler/ From owner-extdom.sctp-impl@sj-core-1.cisco.com Wed Mar 5 16:34:33 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00389 for ; Wed, 5 Mar 2003 16:34:32 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25LSKv2002621; Wed, 5 Mar 2003 13:28:20 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AED39499; Wed, 5 Mar 2003 13:28:19 -0800 (PST) Message-ID: <3E666BF2.9060700@cisco.com> Date: Wed, 05 Mar 2003 15:28:18 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Caitlin Bestler CC: sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Caitlin Bestler wrote: >Section 10.1 (Interface with Upper Layer - ULP-to-SCTP) >specifies: > >o local eligible address list - An address list that the >local SCTP endpoint should bind. By default, if an address >list is not included, all IP addresses assigned to the host >should be used by the local endpoint. > > >When this default is being reused, it is highly plausible >that a restart would result in the list of IP addresses >being different than previously. > >If such a system attempts to restart an association >immediately. Is the peer required to note the changes >in the address list during the peer restart sequence >specified for case A (peer restart) in section 5.4.2 >("Handle a COOKIE ECHO when a TCB exists")? > >Caitlin Bestler >http://asomi.com/CaitlinBestler/ > > > Actually I believe there is wording in the impl-guide that tells you that you MUST not accept such an association if it adds new addresses to it. Otherwise there is a hole that a hacker could use to take over an association... So you are not allowed to add new addresses.. but you can take away addresses from the association. I believe you will get an Abort back with a error cause of restart with new address... or something like that.. check the IG for the "real" procedure... And if you were to get such a scenario.. where a host restarted with a new address and then trys to do a INIT (and never sent an abort or shutdown).. then the only cure is: a) restart the init with less addresse.. then one could shutdown that assoc.. and then restart again with all the addresses (if that was desired) or b) wait a while and try again.. the HB of the peer would eventually illicit a Abort() from the restarted host.. which would then clear out the old TCB and then you could bring up an assoc.. R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Wed Mar 5 17:09:34 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02313 for ; Wed, 5 Mar 2003 17:09:33 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25LxSv2016075 for ; Wed, 5 Mar 2003 13:59:28 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AED44499; Wed, 5 Mar 2003 13:59:27 -0800 (PST) Message-ID: <3E66733E.7060702@cisco.com> Date: Wed, 05 Mar 2003 15:59:26 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sctp-impl@external.cisco.com Subject: Considering Satellite and other Long RTT time communications Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all: As some of you may be aware I have been doing some interesting work at cisco with both TCP and SCTP in a satellite networks. In these networks you have a HIGH RTT time, and possibly HIGH bit error rates.. There are a couple of things implementors can do that I have found make a vast performance improvment and it is something newer SCTP stacks should considering when selecting default parameters. Two key parameters that you might want to contemplate is: 1) Intial Rwnd and 2) Intial cwnd. and 3) max.burst For 1) the higher you can make this the better... since the rwnd will directly limit how much you can have out per RTT... and thus in a high RTT situation it directly limits your throughput even on a zero error channel... Many have done studies with this in TCP.. same is true for SCTP (see papers by Mark Allman and others http://roland.grc.nasa.gov/~mallman/ has a start) I realize that some implementations may not have the memory flexibility to bump this initial value very high..but for general purpose type processors, where you have the flexibility, I would strongly recommend setting this by default to at least 128k... if not higher.. (my bsd implementation will now default to 128k). For 2) this may be a bit controversial but.. currently, in many TCP implementations, if the implementation detects that the destination is on the local lan segment it will set the initial cwnd to 4 segments instead of 2. I would argue that if you detect in the INIT<->INIT-ACK RTT to be over 400ms setting the initial cwnd to 4 might be a good idea as well. Especially when you consider you will not get feedback back from your initial send for close to (or more than) 1/2 second... Sending 4 segments can also enable future algorithms to be applied using packet-pair type technology as well (Mark as a few papers on this on his site...). For 3) Currently max.burst is recommended to be set at 4, for networks with a high RTT.. I think it may be better to have a max.burst in the range of 6-8...mine goes to 8 when the sat.network flag gets turned on... (I keep this flag in the TCB and validate that it stays on at every RTT measurment.. if it swtiches off I penalize the peer that was spoofing me :>) Of course for 2 & 3 you must use the initial-rtt to figure out what type of rules to apply... and you may even want to periodically validate that the peer was not pulling the wool over your eyes as I do :> At minimum number 1 above is a very safe and easy thing to do to assure SCTP will run a bit more optimally over sat networks.. I will also be floating a draft fairly soon on how to address the other property I mentioned :> R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-2.cisco.com Wed Mar 5 17:53:24 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04120 for ; Wed, 5 Mar 2003 17:53:22 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h25MmL0N010959; Wed, 5 Mar 2003 14:48:21 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AED51766; Wed, 5 Mar 2003 14:48:20 -0800 (PST) Message-ID: <3E667EB4.7060902@cisco.com> Date: Wed, 05 Mar 2003 16:48:20 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: niv@us.ibm.com CC: sctp-impl@external.cisco.com Subject: Re: Considering Satellite and other Long RTT time communications References: <3E66733E.7060702@cisco.com> <3E667A8C.8050606@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Nivedita Singhvi wrote: > Randall Stewart (cisco) wrote: > >> Hi all: >> >> As some of you may be aware I have been doing some interesting >> work at cisco with both TCP and SCTP in a satellite networks. >> In these networks you have a HIGH RTT time, and possibly HIGH bit >> error rates.. >> > > Very cool! I was trying to solve performance issues > at a customer site who was doing TCP over satellite > and getting poor performance.. > > I didnt find too much helpful documentation out there, > frankly, and very few real world studies with data.. Most of the work I saw out there was studies and simulations.. Mark as done a lot... > > If you could point me to anything that would help, > I'd appreciate it very much.. > > I found it critical to have large socket buffers, > of course..but also, had problems maintaining a > large enough window to fill the pipe..congestion > window never got above 10 segments.. > > I played around with hacking (evil) up cwnd for TCP, > and yes, I did find upto 10% improvement in just > allowing cwnd to be in the range of 4-6 to begin with.. Yep.. and I don't think this is un-reasonable (bumping to 4).. since its usually a long time until you get feedback and a normal network citizen in 500ms is going to send a lot more than 4 packets... Another thing that will hold you down is the errors. The Error rate is very very bursty in a satellite. And when it bursts you start to either lose packets or you may get a delay... > > However, I found that rtt was very bursty - ave > rtt was 800ms, but every 10th or so packet (including > pings, so this isnt TCP)..would go upto 1600ms, 2500ms, > even 3400ms..seemed to be multiple of rtt times..and > this was a constant feature of the satellite connection.. > I wasnt able to acquire any info regarding why this was > occurring..but it can have nasty effects on TCP - because > you inevitably drop packets, shrink window..and it repeats > up and down..killing performance.. > > Is there anything you can suggest regarding this problem, > short of altering the rtt adjustment code? (I didnt try > anything that severe, although they were in favor of it).. Cisco will be putting out a product (soon) that has our solution in it for TCP.. and even some additional things for SCTP. I will be putting out a draft for SCTP soon as well.. and if you do what the draft says with the technology it makes a TREMENDOUS difference even with error rates of 6% :> > > >> At minimum number 1 above is a very safe and easy thing to do to >> assure SCTP will run a bit more optimally over sat networks.. >> >> I will also be floating a draft fairly soon on how to address >> the other property I mentioned :> > > > I'd be very interested in learning what you suggest for > SCTP - will you be generating anything equivalent for TCP? Soon I wil be posting a draft as I said.. for TCP there are very limtied things that can be done.. and the cisco product will address a lot of these.. the other thing is windows.. get window scaling on and raise your rwnd up in TCP too.. this will help (as you noted).. And of course your send window had better be big for your app to.. otherwise it will never be able to keep the pipe full... R > > thanks, > Nivedita > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Wed Mar 5 20:14:58 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09077 for ; Wed, 5 Mar 2003 20:14:57 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h261AGv2014501; Wed, 5 Mar 2003 17:10:16 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AED72247; Wed, 5 Mar 2003 17:10:15 -0800 (PST) Message-ID: <3E669FF6.1040100@cisco.com> Date: Wed, 05 Mar 2003 19:10:14 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qiaobing Xie CC: sctp-impl@external.cisco.com Subject: Re: Considering Satellite and other Long RTT time communications References: <3E66733E.7060702@cisco.com> <3E6698FD.C3FB8539@Motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Qiaobing Xie wrote: >"Randall Stewart (cisco)" wrote: >... > > >>In these networks you have a HIGH RTT time, and possibly HIGH bit >>error rates.. >> >> > >Maybe this can benefit an over-the-air link in mobile phone networks >too. It has the same properties, plus limited bandwidth. > >-Qiaobing > > > Yep, The technology we are working on should work for mobile systems as well as satellite :> R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-2.cisco.com Wed Mar 5 20:15:00 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09081 for ; Wed, 5 Mar 2003 20:14:59 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2619S0N029254; Wed, 5 Mar 2003 17:09:28 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AED72163; Wed, 5 Mar 2003 17:09:27 -0800 (PST) Message-ID: <3E669FC6.3040102@cisco.com> Date: Wed, 05 Mar 2003 19:09:26 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Caitlin Bestler CC: sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Caitlin Bestler wrote: >On 3/5/03, Randall Stewart (cisco) wrote: > > > > >>Actually I believe there is wording in the impl-guide that >>tells you that you MUST not accept such an association if >>it adds new addresses to it. Otherwise there is a hole >>that a hacker could use to take over an association... >> >>So you are not allowed to add new addresses.. but you can >>take away addresses from the association. >> >> >> >Thanks, I totally missed that on a quick scan because I >was focused on the COOKIE-ECHO, not the INIT. > >Having thought about it, the INIT is the correct place >to catch this. The security hole can be closed at either >place, but when the extra address is legitimate the other >host should get the error feedback as early as possible. > >If there's a further update to the draft you might consider >clarifying the rationale for catching this error during the >INIT as opposed to later. > >There is one unresoled gotcha here though. Section 5.1.2 of >RFC2960 states: > > > >>The time at which the receiver of an INIT resolves the >>host name has potential security implications to SCTP. >>If the receiver of an INIT resolves the host name upon >>the reception of the chunk, and the mechanism the >>receiver uses to resolve the host name involves potential >>long delay (e.g. DNS query), the receiver may open itself >>up to resource attacks for the period of time while it is >>waiting for the name resolution results before it can >>build the State Cookie and release local resources. >> >>Therefore, in cases where the name translation involves >>potential long delay, the receiver of the INIT MUST >>postpone the name resolution till the reception of the >>COOKIE ECHO chunk from the peer. In such a case, the >>receiver of the INIT SHOULD build the State Cookie using >>the received Host Name (instead of destination transport >>addresses) and send the INIT ACK to the source IP address >>from which the INIT was received. >> >> > >Presumably the requirement to reject the restart remains >even if the hostname resolution is deferred to the >COOKIE-ECHO state. > > Yep, Not that you will find many people implementing the Host-Name address... it is just a bit difficult when you consider the kernel implementation ramifications.. and there are other ways to get through nats (which was the reason it was put in)... So far NO implementation at any bakeoff as demonstrated this capability (let alone two implementations). R > >Caitlin Bestler >http://asomi.com/CaitlinBestler/ > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Wed Mar 5 20:43:12 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09722 for ; Wed, 5 Mar 2003 20:43:11 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h261abv2016355 for ; Wed, 5 Mar 2003 17:36:38 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h261abcp002924 for ; Wed, 5 Mar 2003 17:36:37 -0800 (PST) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h261Y0bS013996 for ; Wed, 5 Mar 2003 17:34:02 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.esmtp.ibm.com [9.14.6.103]) by pokfb.esmtp.ibm.com (8.12.8/8.12.2) with ESMTP id h25Mgvga092416 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 5 Mar 2003 17:42:57 -0500 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h25MW4l9051794; Wed, 5 Mar 2003 17:32:04 -0500 Received: from us.ibm.com (sig-9-65-32-214.mts.ibm.com [9.65.32.214]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h25MW1MT136978; Wed, 5 Mar 2003 17:32:02 -0500 Message-ID: <3E667A8C.8050606@us.ibm.com> Date: Wed, 05 Mar 2003 14:30:36 -0800 From: Nivedita Singhvi Reply-To: niv@us.ibm.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: sctp-impl@external.cisco.com Subject: Re: Considering Satellite and other Long RTT time communications References: <3E66733E.7060702@cisco.com> In-Reply-To: <3E66733E.7060702@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: > Hi all: > > As some of you may be aware I have been doing some interesting > work at cisco with both TCP and SCTP in a satellite networks. > In these networks you have a HIGH RTT time, and possibly HIGH bit > error rates.. > Very cool! I was trying to solve performance issues at a customer site who was doing TCP over satellite and getting poor performance.. I didnt find too much helpful documentation out there, frankly, and very few real world studies with data.. If you could point me to anything that would help, I'd appreciate it very much.. I found it critical to have large socket buffers, of course..but also, had problems maintaining a large enough window to fill the pipe..congestion window never got above 10 segments.. I played around with hacking (evil) up cwnd for TCP, and yes, I did find upto 10% improvement in just allowing cwnd to be in the range of 4-6 to begin with.. However, I found that rtt was very bursty - ave rtt was 800ms, but every 10th or so packet (including pings, so this isnt TCP)..would go upto 1600ms, 2500ms, even 3400ms..seemed to be multiple of rtt times..and this was a constant feature of the satellite connection.. I wasnt able to acquire any info regarding why this was occurring..but it can have nasty effects on TCP - because you inevitably drop packets, shrink window..and it repeats up and down..killing performance.. Is there anything you can suggest regarding this problem, short of altering the rtt adjustment code? (I didnt try anything that severe, although they were in favor of it).. > At minimum number 1 above is a very safe and easy thing to do to > assure SCTP will run a bit more optimally over sat networks.. > > I will also be floating a draft fairly soon on how to address > the other property I mentioned :> I'd be very interested in learning what you suggest for SCTP - will you be generating anything equivalent for TCP? thanks, Nivedita From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 6 03:49:41 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28600 for ; Thu, 6 Mar 2003 03:49:40 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h268Vev2011675 for ; Thu, 6 Mar 2003 00:31:41 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h268Ve7w012759 for ; Thu, 6 Mar 2003 00:31:40 -0800 (PST) Received: from 141WEB01 ([195.75.129.54]) by proxy3.cisco.com (8.12.8/8.11.2) with SMTP id h268VY1S017862 for ; Thu, 6 Mar 2003 00:31:42 -0800 (PST) Received: from hv.8g98o.net [9.214.148.142] by 141WEB01 with ESMTP id 87962013; Thu, 06 Mar 2003 10:26:36 +0200 Message-ID: From: "Kay Wills" To: Subject: Order Viagra, Diet Pills & more with NO PRESCRIPTION! US doctors and pharmacies! Overnight Shipping Date: Thu, 06 Mar 03 10:26:36 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0C41BAA_1CDF4B63" This is a multi-part message in MIME format. --0C41BAA_1CDF4B63 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Order Confirmation. = Your order should be shipped by January, via FedEx. Your Federal Express tracking n= umber is.
Thank you for registering.
Wholesale Prescription Medications!
OUR DOCTORS WILL WRITE YOU A PRESCRIPTION FOR F= REE
Buy Your Prescription Meds On= line

Lowest Prices – No Prior Prescription Required
Click Here

Upon Approval, Our = US Licensed Doctors will Prescribe Your Medication For Free
And Have the Medication Shipped Overnight To Your Door.

We assure you the= absolute best value on the Internet.
Click Here

Medications for: = Weight Loss, Pain Relief, Muscle Pain Relief, Women's Health, Men's Health, <= br> Impotence, Allergy Relief, Heartburn Relief, Migraine Relief

Medications like:= Phentermine, Adipex, Soma, Fioricet, Ultram, Celebrex,
Viagra, Valtrex, Zyban, and many, many more.

Click = Here

remove me from your list

hz r sa hzvhhzmatjenhdtixaui yio bwjrpnd hmbubyxkqri fyc --0C41BAA_1CDF4B63-- From owner-extdom.sctp-impl@sj-core-2.cisco.com Thu Mar 6 03:49:57 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28616 for ; Thu, 6 Mar 2003 03:49:55 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h268V90N016277 for ; Thu, 6 Mar 2003 00:31:10 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h268V97w012306 for ; Thu, 6 Mar 2003 00:31:09 -0800 (PST) Received: from pool-151-199-52-40.bos.east.verizon.net (pool-151-199-52-40.bos.east.verizon.net [151.199.52.40]) by proxy2.cisco.com (8.12.8/8.11.2) with SMTP id h268SebS013892 for ; Thu, 6 Mar 2003 00:28:47 -0800 (PST) Received: from kgqy.t8qzy3.org (HELO en02uqy) ([111.2.219.88]) by pool-151-199-52-40.bos.east.verizon.net for ; Thu, 06 Mar 2003 11:27:51 +0300 Message-ID: From: "Beth Guzman" To: Subject: Viagra, Soma, Fioricet, Prescribed Online for Free, Shipped Overnight Date: Thu, 06 Mar 03 11:27:51 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0C41BAA_1CDF4B63" This is a multi-part message in MIME format. --0C41BAA_1CDF4B63 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Order Confirmation. = Your order should be shipped by January, via FedEx. Your Federal Express tracking n= umber is.
Thank you for registering.
Wholesale Prescription Medications!
OUR DOCTORS WILL WRITE YOU A PRESCRIPTION FOR F= REE
Buy Your Prescription Meds On= line

Lowest Prices – No Prior Prescription Required
Click Here

Upon Approval, Our = US Licensed Doctors will Prescribe Your Medication For Free
And Have the Medication Shipped Overnight To Your Door.

We assure you the= absolute best value on the Internet.
Click Here

Medications for: = Weight Loss, Pain Relief, Muscle Pain Relief, Women's Health, Men's Health, <= br> Impotence, Allergy Relief, Heartburn Relief, Migraine Relief

Medications like:= Phentermine, Adipex, Soma, Fioricet, Ultram, Celebrex,
Viagra, Valtrex, Zyban, and many, many more.

Click = Here

remove me from your list

k o xxosu --0C41BAA_1CDF4B63-- From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 6 07:40:24 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09332 for ; Thu, 6 Mar 2003 07:40:22 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26CUpv2020550 for ; Thu, 6 Mar 2003 04:30:51 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEE16170; Thu, 6 Mar 2003 04:30:50 -0800 (PST) Message-ID: <3E673F79.1040900@cisco.com> Date: Thu, 06 Mar 2003 06:30:49 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sctp-impl@external.cisco.com Subject: Security Issue for users of OpenSS7 References: <20030303135341.I16782@openss7.org> <3E63C6FF.9040104@cisco.com> <20030303151206.J16782@openss7.org> <3E63DE21.3080304@cisco.com> <20030303163628.N16782@openss7.org> <3E63F37B.7040500@cisco.com> <20030303175007.A26066@openss7.org> <3E640EF5.7020108@cisco.com> <20030303233203.B32643@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Users of OpenSS7.. I want you to pay special attention to this email and understand the security issues involved in not defining the variable: SCTP_SLOW_VERIFICATION See below Brian F. G. Bidulock wrote: >Randall, > >On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian F. G. Bidulock wrote: >> >> >> >>>Randall, >>> >>>On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: >>> >>> >>> >>> >>> >>>> >>>> >>1) By using the Vtags for a hash lookup you have serverly compromised >> the security associated with them. I have spent a bit more time >>reviewing >> your code.. and basically anytime the source port and Vtag match >> you ship the packet up the stream to the processing layer of your SCTP >> stack. This means that if I know a port that you are likely to have a >> listener , say for example we are using SCTP for http.. not to far >> fetched.. and I know there will be quite some number of connections >> (invision CNN or google)... then instead of having a 1 in 4 billion >> chance of guessing a Vtag.. I now have a N in 4 billion chance >> (where N is the number of connections you have up right now) and >> even more so I don't even need to know a source address and >> port you think are valid.. you don't care.. you will accept any as >> long as the V-tag and destination port are correct. This is an extreme >> mis-use of a security feature that works to compromise the >> security put into the protocol.. I doubt that the IESG would support >> such mis-use of a feature in the protocol. >> >> > >IP addresses are trivial to spoof. There is no security afforded in addition >to the VT by adding spoofable IP addresses to the match. If you need >security, I suggest you (re)read the security section of RFC 2960. ;) > > > >> >> Has Brian mentions above, anyone can spoof IP addresses.. So lets consider blind attackers and there needs for a moment (TCP, SCTP-with-slow-verify (address matching), SCTP-vtag/port matching). Protocol | Needed to guess by the hacker -------------------+--------------------------------------------------------------- TCP | Dest IP addr, Dest Port, Src IP addr, Src Port SCTP-addr | Dest IP addr, Dest Port, Src IP addr, Src Port, V-tag SCTP-vtag | Dest port, Vtag Now For all cases, we can discard the Dest IP address and port.. this is a simple to guess.. i.e. I know your IP address and KNOW you are running a XXX server at Port YYY. So for TCP we need to guess a 32 bit source IP address of an existing peer and a 16 bit port number of an existing peer... This yeilds at most 48 bits of protection. I say at most due to the fact that the port space is probably smaller since it is a pretty good bet the src is a dynamic port which may have a more limited range... i.e. figure out what TCP port range, dynamically, windows uses and this narrows the bits some.. Conclusion - TCP provides 48 bits of protection, at most, against blind attacks. Now for SCTP-addr we need to guess the same 48 bits again but we add to this a 32 bit V-tag. And in this 32 bit V-tag you must guess the single one (no matter how many associations are up on the machine) that goes with the pariticular source address and port of the victim's peer. This means you get the same 48 bits PLUS a full additional 32 bits of protection so: Conclusion SCTP-addr provides 80 bits of protection (at most for the same discussion of the port issue I made in TCP) against blind attacks. Now for SCTP-vtag - Here we blindly take any valid V-tag that is in the system on any active association.. we don't care what the addresses are.. all we look at is the V-tag and destination port. The destination port is, as we discussed, easily guessable.. so we can dis-qualify that. Instead we have a N in 32bit chance of getting a packet accepted.. where N is the number of active associations up on the machine. Conclusion SCTP-vtag provides less than 32 bits of protection against blind attack's being substantially weaker than even plain old TCP. Another interesting side note is that SCTP depends on the V-tag to also filter out mis-routed packets as well.. (TCP uses a pseudo header in the checksum for this purpose) A mis-routed packet has less than a 1 in 4billion chance of being accepted by SCTP-addr since the mis-routed packet must also have a source/dest port that matches an existing association and the complete V-Tag space is available you have a 1 in the full 32 bits of getting the mis-routed packet through.. i.e. the same 80bit protection is afforded.. SCTP-vtag on the other hand, only has to have the destination port match any existing destination port and then you get a N in 32 bit chance of getting the mis-routed packet through.. So: What can you do to protect yourself if you are using this implementation? Make sure SCTP_SLOW_VERIFICATION is defined in your build. This will change the code to do: #define sctp_match_vtag(__sp, __saddr, __daddr, __v_tag, __sport, __dport) \ ( ((__v_tag) == (__sp)->v_tag) && \ ((__sport) == (__sp)->sport) && \ ((__dport) == (__sp)->dport) && \ (sctp_find_saddr((__sp),(__daddr))) && \ (sctp_find_daddr((__sp),(__saddr))) ) instead of the much weaker: #define sctp_match_vtag(__sp, __saddr, __daddr, __v_tag, __sport, __dport) \ ( ((__v_tag) == (__sp)->v_tag) && \ ((__sport) == (__sp)->sport) ) In finding associations. One dis-advantage to this approach however, is you will have to make sure that ALL addresses of the peers are known when you open a listening endpoint.. otherwise some of the scenarios discussed in the matching discussion will occcur and associations could fail to start up.. Regards R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 6 08:37:31 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13418 for ; Thu, 6 Mar 2003 08:37:29 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26DVNv2023033 for ; Thu, 6 Mar 2003 05:31:23 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h26DVMcp010854 for ; Thu, 6 Mar 2003 05:31:23 -0800 (PST) Received: from gw.openss7.com (IDENT:4gxJL6yCUIjmBZnhkgB0qOc4C+NNyuFn@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h26DSwbS017151 for ; Thu, 6 Mar 2003 05:29:04 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:m/SRfxnInk8LRWiB/mM8Ru3busEWipYf@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h26DOjD21201 for ; Thu, 6 Mar 2003 06:24:45 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h26DOiQ02462 for sctp-impl@external.cisco.com; Thu, 6 Mar 2003 06:24:44 -0700 Date: Thu, 6 Mar 2003 06:24:44 -0700 From: "Brian F. G. Bidulock" To: sctp-impl@external.cisco.com Subject: Re: Security Issue for users of OpenSS7 Message-ID: <20030306062444.C2350@openss7.org> Reply-To: bidulock@openss7.org References: <20030303135341.I16782@openss7.org> <3E63C6FF.9040104@cisco.com> <20030303151206.J16782@openss7.org> <3E63DE21.3080304@cisco.com> <20030303163628.N16782@openss7.org> <3E63F37B.7040500@cisco.com> <20030303175007.A26066@openss7.org> <3E640EF5.7020108@cisco.com> <20030303233203.B32643@openss7.org> <3E673F79.1040900@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E673F79.1040900@cisco.com>; from rrs@cisco.com on Thu, Mar 06, 2003 at 06:30:49AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, Your warning is about 2 years behind mine: Slow Verification CONFIG_SCTP_SLOW_VERIFICATION When a message comes from an SCTP endpoint with the correct verification tag, it is not necessary to check whether it is from a correct source address to identify the SCTP association to which it belongs. When you say N here, source addresses are not checked and it is up to firewall implementations to thwart attackers of the verification tag. When you say Y here, you get RFC 2960 compliant operation, but at a great cost to SCTP performance. Also, see below... On Thu, 06 Mar 2003, Randall Stewart (cisco) wrote: > Users of OpenSS7.. > > I want you to pay special attention to this email and > understand the security issues involved in not defining the > variable: > > SCTP_SLOW_VERIFICATION > > See below > > Brian F. G. Bidulock wrote: > > >Randall, > > > >On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > > > > > > > >>Brian F. G. Bidulock wrote: > >> > >> > >> > >>>Randall, > >>> > >>>On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > >>> > >>> > >>> > >>> > >>> > >>>> > >>>> > >>1) By using the Vtags for a hash lookup you have serverly compromised > >> the security associated with them. I have spent a bit more time > >>reviewing > >> your code.. and basically anytime the source port and Vtag match > >> you ship the packet up the stream to the processing layer of your SCTP > >> stack. This means that if I know a port that you are likely to have a > >> listener , say for example we are using SCTP for http.. not to far > >> fetched.. and I know there will be quite some number of connections > >> (invision CNN or google)... then instead of having a 1 in 4 billion > >> chance of guessing a Vtag.. I now have a N in 4 billion chance > >> (where N is the number of connections you have up right now) and > >> even more so I don't even need to know a source address and > >> port you think are valid.. you don't care.. you will accept any as > >> long as the V-tag and destination port are correct. This is an extreme > >> mis-use of a security feature that works to compromise the > >> security put into the protocol.. I doubt that the IESG would support > >> such mis-use of a feature in the protocol. > >> > >> > > > >IP addresses are trivial to spoof. There is no security afforded in addition > >to the VT by adding spoofable IP addresses to the match. If you need > >security, I suggest you (re)read the security section of RFC 2960. ;) > > > > > > > >> > >> > Has Brian mentions above, anyone can spoof IP addresses.. So lets > consider blind attackers > and there needs for a moment (TCP, SCTP-with-slow-verify (address > matching), SCTP-vtag/port matching). > > Protocol | Needed to guess by the hacker > -------------------+--------------------------------------------------------------- > TCP | Dest IP addr, Dest Port, Src IP addr, Src Port > SCTP-addr | Dest IP addr, Dest Port, Src IP addr, Src Port, V-tag > SCTP-vtag | Dest port, Vtag > > Now For all cases, we can discard the Dest IP address and port.. this is > a simple to guess.. i.e. I know your IP address and KNOW you are > running a XXX server at Port YYY. Source port is a simple guess too. > > So for TCP we need to guess a 32 bit source IP address of an existing > peer and a 16 bit port number of an existing peer... This yeilds at most > 48 bits of protection. I say at most due to the fact that the port space is > probably smaller since it is a pretty good bet the src is a dynamic port > which may have a more limited range... i.e. figure out what TCP port > range, dynamically, windows uses and this narrows the bits some.. > > Conclusion - TCP provides 48 bits of protection, at most, against > blind attacks. > > Now for SCTP-addr we need to guess the same 48 bits again but > we add to this a 32 bit V-tag. And in this 32 bit V-tag you must > guess the single one (no matter how many associations are up > on the machine) that goes with the pariticular source address and > port of the victim's peer. This means you get the same 48 bits PLUS > a full additional 32 bits of protection so: > > Conclusion SCTP-addr provides 80 bits of protection (at most for > the same discussion of the port issue I made in TCP) against blind > attacks. > > Now for SCTP-vtag - Here we blindly take any valid V-tag that > is in the system on any active association.. we don't care what the > addresses are.. all we look at is the V-tag and destination port. The > destination port is, as we discussed, easily guessable.. so we can > dis-qualify that. Instead we have a N in 32bit chance of getting > a packet accepted.. where N is the number of active associations > up on the machine. > > Conclusion SCTP-vtag provides less than 32 bits of protection > against blind attack's being substantially weaker than even > plain old TCP. > > Another interesting side note is that SCTP depends on the V-tag > to also filter out mis-routed packets as well.. (TCP uses a pseudo > header in the checksum for this purpose) A mis-routed packet > has less than a 1 in 4billion chance of being accepted by SCTP-addr > since the mis-routed packet must also have a source/dest port that matches > an existing association and the complete V-Tag space is available > you have a 1 in the full 32 bits of getting the mis-routed packet through.. > i.e. the same 80bit protection is afforded.. > > SCTP-vtag on the other hand, only has to have the destination port > match any existing destination port and then you get a N in 32 bit > chance of getting the mis-routed packet through.. > > So: What can you do to protect yourself if you are using this > implementation? > > Make sure SCTP_SLOW_VERIFICATION is defined in your build. This will change > the code to do: > > #define sctp_match_vtag(__sp, __saddr, __daddr, __v_tag, __sport, __dport) \ > ( ((__v_tag) == (__sp)->v_tag) && \ > ((__sport) == (__sp)->sport) && \ > ((__dport) == (__sp)->dport) && \ > (sctp_find_saddr((__sp),(__daddr))) && \ > (sctp_find_daddr((__sp),(__saddr))) ) > > instead of the much weaker: > > #define sctp_match_vtag(__sp, __saddr, __daddr, __v_tag, __sport, __dport) \ > ( ((__v_tag) == (__sp)->v_tag) && \ > ((__sport) == (__sp)->sport) ) > > In finding associations. > > > One dis-advantage to this approach however, is you will have to make > sure that ALL addresses > of the peers are known when you open a listening endpoint.. otherwise > some of the scenarios > discussed in the matching discussion will occcur and associations could > fail to > start up.. Associations will not fail to start up, even with the static port examples given by Caitlin, Ivan and yourself. --brian > > > Regards > > R > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-2.cisco.com Thu Mar 6 08:47:01 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14162 for ; Thu, 6 Mar 2003 08:46:59 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26DVD0N019952 for ; Thu, 6 Mar 2003 05:31:13 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h26DUXYg010026 for ; Thu, 6 Mar 2003 05:30:33 -0800 (PST) Received: from gw.openss7.com (IDENT:rCGVA/D8qPH+jmJAGsF1Zk/G5V1we04+@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h26DSubS016956 for ; Thu, 6 Mar 2003 05:29:02 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:Y4f8o0WDoenLMLflh+6104OIXoCiEscb@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h26DOAD21199 for ; Thu, 6 Mar 2003 06:24:10 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h26DO9s02457 for sctp-impl@external.cisco.com; Thu, 6 Mar 2003 06:24:09 -0700 Date: Thu, 6 Mar 2003 06:24:09 -0700 From: "Brian F. G. Bidulock" To: sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart Message-ID: <20030306062409.B2350@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Wed, Mar 05, 2003 at 02:44:42PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Caitlin, IG Section 2.6 would have you refuse the INIT with a new error code if addresses are added. But this is not necessary if one uses the source address of the packet rather than the source address list. Consider the following: HOST A/B HOST C/D -------- -------- Existing assocation (A/B:1000 <-> C/D:9999) <==================================================> Attacker sends (Z:1000->C:9999, (A,B)) -------------------------------------------> Section 2.6 of the IG says that HOST C/D must refuse this init. The reason for refusing at the INIT stage instead of waiting for COOKIE-ECHO is that if HOST C/D sends an INIT-ACK with tie tags populated, it will be exposing both VTs of the existing association in the tie tag (the cookie is not encrypted, only hashed). However, if we look up on Z:1000,C/D:9999 (only the information from the packet headers) we will not find the existing association and will set tie tags to zero (0). If the attacker sends a COOKIE-ECHO, as it has tie tags of zero and there is an existing association we apply Action (C) and discard the COOKIE-ECHO and the attacker is thwarted. INIT-ACK (Z:1000<-C/D:9999, (D/C), tie tags 0) <------------------------------------------- COOKIE-ECHO (tie tags 0) -------------------------------------------> Discard Action (C) Note that if the attacker uses address A or B as the source address in the INIT, the INIT-ACK will be sent to A or B and discarded there because there is no oustanding INIT with the given verification tag. This approach is superior to that of IG Section 2.6 because it permits restarts sent from existing addresses (A or B in the example) to add addresses to the list, but thwarts the outside attack. Also, no exhaustive searches of arbitrarily long address lists is required (searching address lists opens one up to other attacks). So, for example, HOST A/B HOST C/D -------- -------- Existing assocation (A/B:1000 <-> C/D:9999) <==================================================> HOST A/B Restarts with additional address Z. INIT (A:1000->C:9999, (B,Z)) ---------------------------------------------------> Section 2.6 of the IG would have you refuse this INIT. If HOST C/D looks up the association on packet header information only, it will find the existing assocation, populate tie tags and the restart will complete: INIT-ACK (A:1000<-C/D:9999, (D/C), tie tags set) <--------------------------------------------------- COOKIE-ECHO (tie tags set) ---------------------------------------------------> Restart Action (A) COOKIE-ACK <--------------------------------------------------- Of course if HOST A/B restarts and attempts to restart the association with address Z as the initial primary, then the initialization attempt will time-out in COOKIE-ECHOED state, however, a HEARTBEAT should have destroyed the initial assocation by that time and a simply retry by the ULP will succeed. So, if you want to support hosts that restart with additional IP addresses (quite plausible as you say), IMO you would be best to ignore both IG Section 2.6 and IG Section 2.18. This is how our implementation has functioned for years now. --brian On Wed, 05 Mar 2003, Caitlin Bestler wrote: > Section 10.1 (Interface with Upper Layer - ULP-to-SCTP) > specifies: > > o local eligible address list - An address list that the > local SCTP endpoint should bind. By default, if an address > list is not included, all IP addresses assigned to the host > should be used by the local endpoint. > > > When this default is being reused, it is highly plausible > that a restart would result in the list of IP addresses > being different than previously. > > If such a system attempts to restart an association > immediately. Is the peer required to note the changes > in the address list during the peer restart sequence > specified for case A (peer restart) in section 5.4.2 > ("Handle a COOKIE ECHO when a TCB exists")? > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 6 09:00:42 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14897 for ; Thu, 6 Mar 2003 09:00:40 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26DsUv2017839 for ; Thu, 6 Mar 2003 05:54:31 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h26DrpYg000044 for ; Thu, 6 Mar 2003 05:53:52 -0800 (PST) Received: from gw.openss7.com (IDENT:wmfmTyz47yIG19uohHCYTv39qCT+Q+nq@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h26DsFQT011220 for ; Thu, 6 Mar 2003 05:54:17 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:3+L4/I/JZhfphQj9umNMiqj0ofcjKipo@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h26DlQD21613 for ; Thu, 6 Mar 2003 06:47:26 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h26DlPg03001 for sctp-impl@external.cisco.com; Thu, 6 Mar 2003 06:47:25 -0700 Date: Thu, 6 Mar 2003 06:47:25 -0700 From: "Brian F. G. Bidulock" To: sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart Message-ID: <20030306064725.A2588@openss7.org> Reply-To: bidulock@openss7.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Caitlin, IG Section 2.6 would have you refuse the INIT with a new error code if addresses are added. But this is not necessary if one uses the source address of the packet rather than the source address list. Consider the following: HOST A/B HOST C/D -------- -------- Existing assocation (A/B:1000 <-> C/D:9999) <==================================================> Attacker sends (Z:1000->C:9999, (A,B)) -------------------------------------------> Section 2.6 of the IG says that HOST C/D must refuse this init. The reason for refusing at the INIT stage instead of waiting for COOKIE-ECHO is that if HOST C/D sends an INIT-ACK with tie tags populated, it will be exposing both VTs of the existing association in the tie tag (the cookie is not encrypted, only hashed). However, if we look up on Z:1000,C/D:9999 (only the information from the packet headers) we will not find the existing association and will set tie tags to zero (0). If the attacker sends a COOKIE-ECHO, as it has tie tags of zero and there is an existing association we apply Action (C) and discard the COOKIE-ECHO and the attacker is thwarted. INIT-ACK (Z:1000<-C/D:9999, (D/C), tie tags 0) <------------------------------------------- COOKIE-ECHO (tie tags 0) -------------------------------------------> Discard Action (C) Note that if the attacker uses address A or B as the source address in the INIT, the INIT-ACK will be sent to A or B and discarded there because there is no oustanding INIT with the given verification tag. This approach is superior to that of IG Section 2.6 because it permits restarts sent from existing addresses (A or B in the example) to add addresses to the list, but thwarts the outside attack. Also, no exhaustive searches of arbitrarily long address lists is required (searching address lists opens one up to other attacks). So, for example, HOST A/B HOST C/D -------- -------- Existing assocation (A/B:1000 <-> C/D:9999) <==================================================> HOST A/B Restarts with additional address Z. INIT (A:1000->C:9999, (B,Z)) ---------------------------------------------------> Section 2.6 of the IG would have you refuse this INIT. If HOST C/D looks up the association on packet header information only, it will find the existing assocation, populate tie tags and the restart will complete: INIT-ACK (A:1000<-C/D:9999, (D/C), tie tags set) <--------------------------------------------------- COOKIE-ECHO (tie tags set) ---------------------------------------------------> Restart Action (A) COOKIE-ACK <--------------------------------------------------- Of course if HOST A/B restarts and attempts to restart the association with address Z as the initial primary, then the initialization attempt will time-out in COOKIE-ECHOED state, however, a HEARTBEAT should have destroyed the initial assocation by that time and a simply retry by the ULP will succeed. So, if you want to support hosts that restart with additional IP addresses (quite plausible as you say), IMO you would be best to ignore both IG Section 2.6 and IG Section 2.18. This is how our implementation has functioned for years now. --brian On Wed, 05 Mar 2003, Caitlin Bestler wrote: > Section 10.1 (Interface with Upper Layer - ULP-to-SCTP) > specifies: > > o local eligible address list - An address list that the > local SCTP endpoint should bind. By default, if an address > list is not included, all IP addresses assigned to the host > should be used by the local endpoint. > > > When this default is being reused, it is highly plausible > that a restart would result in the list of IP addresses > being different than previously. > > If such a system attempts to restart an association > immediately. Is the peer required to note the changes > in the address list during the peer restart sequence > specified for case A (peer restart) in section 5.4.2 > ("Handle a COOKIE ECHO when a TCB exists")? > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 6 09:00:49 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14919 for ; Thu, 6 Mar 2003 09:00:47 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26Dt9v2018549 for ; Thu, 6 Mar 2003 05:55:10 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h26DsUYg000637 for ; Thu, 6 Mar 2003 05:54:30 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h26Dq2bS005668 for ; Thu, 6 Mar 2003 05:52:05 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26DR9F26623 for ; Thu, 6 Mar 2003 15:27:09 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 15:23:49 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 15:23:49 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 15:23:48 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 15:23:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Thu, 6 Mar 2003 15:22:42 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLijRGBEtz2OuZuRvWjdjqAClZI5gBU7KKQ From: To: Cc: , , X-OriginalArrivalTime: 06 Mar 2003 13:23:20.0237 (UTC) FILETIME=[8E2FBDD0:01C2E3E3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA14919 Brian, > Ivan.Arias-Rodriguez, > > On Tue, 04 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > Hi! > > > > So this is the example of INIT collision. It is the > typical one, when > > both peers start about at the same time. This is the > notation used: > > > > - For all the chunks: > > o In capital letters the NAME OF CHUNK. > > o VT is the Verification Tag included in the > SCTP header. > > o Source Address:Port->Destination Address:Port. > > > > - For INIT and INIT ACK: > > o IT is the Initiation Tag included in the > header of the chunk. > > > > - For INIT ACK and COOKIE ECHO: > > o VTloc and VTpeer are the values of the local > Verification > > Tag (the one the INIT ACK sender expects in the > SCTP headers > > of the peer) and the peer's Verification Tag > (the one the INIT > > ACK senders includes in its SCTP headers) as > included in the > > State Cookie. Note that those values are > directly copied from > > the INIT ACK and included in the COOKIE ECHO. > > > o TTloc and TTpeer are the values of the local > Tie Tag (the > > value of VTloc at the moment of sending the > INIT ACK) and the > > peer's Tie Tag (the value of VTpeer at the > moment of sending > > the INIT ACK) as included in the State Cookie. > Note that those > > values are directly copied from the INIT ACK > and included in > > the COOKIE ECHO. > > > > The TCBs are only shown when there is a change. They show: > > - Source address/es:Source Port. > > - Destination address/es: Destination Port. > > - Local Verification Tag. > > - Peers Verification Tag. > > - State. > > > > Let's see the scenario. > > > > > > Host A > Host B/C > > > > TCB \ INIT VT:0 IT:W INIT VT:0 > IT:X / TCB > > A:1000 \ A:1000->B:1000 > ?:1000->A:1000 / B,C:1000 > > B:1000 \ > / A:1000 > > VTloc:W \ > / VTloc:X > > VTpeer:0 \ > / VTpeer:0 > > C-WAIT \ > / C-WAIT > > \--------------------\ /--------------------/ > > \/ > > /\ > > / \ > > (1) <-------------------------/ \-------------------------> > > > > \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:X / > > \ A:1000->C:1000 B:1000->A:1000 / > > \ VTloc:Y VTpeer:X VTloc:X VTpeer:W / > > \TTloc:0 TTpeer:0 TTloc:X TTpeer:0/ > > \ / > > \ / > > \--------------------\ /--------------------/ > > \/ > > /\ > > / \ > > <-------------------------/ \-------------------------> > > > > TCB \ COOKIE ECHO VT:X COOKIE ECHO > VT:Y / TCB > > A:1000 \ A:1000->B:1000 > C:1000->A:1000 / B,C:1000 > > B,C:1000 \ VTloc:X VTpeer:W VTloc:Y > VTpeer:W / A:1000 > > VTloc:W \TTloc:X TTpeer:0 TTloc:0 > TTpeer:0/ VTloc:X > > VTpeer:X \ > / VTpeer:Y > > C-ECHOED \ > / C-ECHOED > > \--------------------\ /--------------------/ > > \/ > > /\ > > / \ > > (2) X<-------------------------/ > \-------------------------> (3) > > > > COOKIE ACK > VT:W / TCB > > > / B,C:1000 > > > / A:1000 > > > / VTloc:X > > > / VTpeer:W > > > / ESTABLISH > > /--------------------/ > > / > > / > > / > > (4) X<-------------------------/ > > > > > > > > Some remarks: > > > > (1) At this point, Host A doesn't recognize the INIT as > coming from > > the same association it is trying to establish. The VT > is completely > > different. Thus, it goes in the normal (and wrong) establishment > > procedure, creates a new IT and set the Tie Tags to 0. > > > > (2) The received COOKIE ECHO is discarded, since the VT > is wrong (Host > > A is expecting VT set to W). > > > > (3) Host B,C recognizes the collision due to the Tie > Tags, recognize > > it as situation B of section 5.2.4 and updates the VTpeer to W. > > > > (4) The COOKIE ACK is discarded, since Host A is in the > C-ECHOED state. > > > > > > And now? > > > > Host A will retransmit the COOKIE ECHO, Host B,C will > answer again, > > and the COOKIE ACK is discarded again. > > > > Conclusion: Host A cannot establish an association with > Host B,C in > > this situation. > > > > Brian, did I make any mistake? I hope I didn't... :-/ > > In both our STREAMS and Sockets implementations you cannot bind to a > static port when another STREAM/Socket is bound to that port as a > listener. That's just how STREAMS/Socket semantics work. I don't understand this... Do you mean that the address/port that sent the INIT is not listening? I think that since the very moment it sent the INIT it should be listening for the INIT ACK... But, what a pity, it receives an INIT instead of the expected INIT ACK... I'm sorry, I'm missing something... :-/ > If Host A is our implementation, the INIT from Host B/C for A:1000 > will be refused because there is no STREAM/Socket listening on that > port and only one association will form. Then the situation is even more obvious... If Host B/C also uses the same implementation, no INIT will ever be read -> no association formed... What am I missing? > If Host B/C is our implemenataion, the INIT from Host A for B/C:1000 > will be refused because there is no listening socket. I don't understand... Well, Yes... I imagine that the point is that nobody will send an INIT to a non-static port... ok... But this is a limitation... Otherwise, why caring at all about collisions? So far in all the interoperability test sessions I have been, I have tested successfully the collision scenario, i.e., other implementations where also able to send an INIT from a static port... :-/ > This is no different in TCP/Sockets. TCP sockets do not allow you > to bind to a static port and address if there is a socket listening > on that port. You cannot even make two TCP sockets implementations > do what you describe here. I don't know about TCP implementations. I just know that my implementation (and most of all of the other ones) are able to do it... We were both able to tell the other, ok, to which port are you going to send the INIT? ... alright, I will be listening there... And then we managed to test the INIT collision scenario... > Because our implementation follows standard XTI/XNS and Sockets > semantics at most one association will form and there will be none of > the problems you describe. Again, you are talking about your specific implementation... If you start putting special conditions, such as this one, that you know in advance the peer's addresses... then there will be a moment in which you don't even need to check the VT... > You seem to focus on collisions (which are not possible using Sockets) > and Caitlin focusses on two ULPs launching from the same > static address > (which is heavily discouraged in Sockets with SO_REUSEADDR and is not > possible unless the flag is set on ALL sockets using the address and > NO listening sockets). There are several different scenarios... INIT collision, the one Caitlin says, restart with more addresses... Ok, they won't happen everyday, but they are there... > You both dig down into the little unused corner case of static port > assignment to justify a SHOULD on "how to search"? I think you have just said that we are right... Do we want the test to be changed to say "you SHOULD do that unless: a) You know all the addresses of all the peers that might connect to you. b) You never send an INIT to a non-static port and you expect your peers to do the same. c) Any Brian's implementation special features... ? :-0... BR Iván Arias Rodríguez > --brian > > > > > > > > BR Iván Arias Rodríguez > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 6 09:00:53 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14941 for ; Thu, 6 Mar 2003 09:00:51 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26DtCv2018609; Thu, 6 Mar 2003 05:55:13 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEE19680; Thu, 6 Mar 2003 05:55:11 -0800 (PST) Message-ID: <3E67533F.9080302@cisco.com> Date: Thu, 06 Mar 2003 07:55:11 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: sctp-impl@external.cisco.com Subject: Re: Security Issue for users of OpenSS7 References: <20030303135341.I16782@openss7.org> <3E63C6FF.9040104@cisco.com> <20030303151206.J16782@openss7.org> <3E63DE21.3080304@cisco.com> <20030303163628.N16782@openss7.org> <3E63F37B.7040500@cisco.com> <20030303175007.A26066@openss7.org> <3E640EF5.7020108@cisco.com> <20030303233203.B32643@openss7.org> <3E673F79.1040900@cisco.com> <20030306062444.C2350@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >Your warning is about 2 years behind mine: > > Slow Verification > CONFIG_SCTP_SLOW_VERIFICATION > When a message comes from an SCTP endpoint with the correct > verification tag, it is not necessary to check whether it is from > a correct source address to identify the SCTP association to > which it belongs. When you say N here, source addresses are not > checked and it is up to firewall implementations to thwart > attackers of the verification tag. When you say Y here, you get > RFC 2960 compliant operation, but at a great cost to SCTP > performance. > >Also, see below... > So, you admit that using V-Tags weakens security .. which was the entire purpose of the V-Tag... > >On Thu, 06 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Users of OpenSS7.. >> >>I want you to pay special attention to this email and >>understand the security issues involved in not defining the >>variable: >> >>SCTP_SLOW_VERIFICATION >> >>See below >> >>Brian F. G. Bidulock wrote: >> >> >> >>>Randall, >>> >>>On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: >>> >>> >>> >>> >>> >>>>Brian F. G. Bidulock wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Randall, >>>>> >>>>>On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>1) By using the Vtags for a hash lookup you have serverly compromised >>>> the security associated with them. I have spent a bit more time >>>>reviewing >>>> your code.. and basically anytime the source port and Vtag match >>>> you ship the packet up the stream to the processing layer of your SCTP >>>> stack. This means that if I know a port that you are likely to have a >>>> listener , say for example we are using SCTP for http.. not to far >>>> fetched.. and I know there will be quite some number of connections >>>> (invision CNN or google)... then instead of having a 1 in 4 billion >>>> chance of guessing a Vtag.. I now have a N in 4 billion chance >>>> (where N is the number of connections you have up right now) and >>>> even more so I don't even need to know a source address and >>>> port you think are valid.. you don't care.. you will accept any as >>>> long as the V-tag and destination port are correct. This is an extreme >>>> mis-use of a security feature that works to compromise the >>>> security put into the protocol.. I doubt that the IESG would support >>>> such mis-use of a feature in the protocol. >>>> >>>> >>>> >>>> >>>IP addresses are trivial to spoof. There is no security afforded in addition >>>to the VT by adding spoofable IP addresses to the match. If you need >>>security, I suggest you (re)read the security section of RFC 2960. ;) >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>Has Brian mentions above, anyone can spoof IP addresses.. So lets >>consider blind attackers >>and there needs for a moment (TCP, SCTP-with-slow-verify (address >>matching), SCTP-vtag/port matching). >> >>Protocol | Needed to guess by the hacker >>-------------------+--------------------------------------------------------------- >> TCP | Dest IP addr, Dest Port, Src IP addr, Src Port >> SCTP-addr | Dest IP addr, Dest Port, Src IP addr, Src Port, V-tag >> SCTP-vtag | Dest port, Vtag >> >>Now For all cases, we can discard the Dest IP address and port.. this is >>a simple to guess.. i.e. I know your IP address and KNOW you are >>running a XXX server at Port YYY. >> >> > >Source port is a simple guess too. > > Yes, as I say below... you have a limited range that dynamic ports are assigned from... but of course you don't have to use a dynamic port to start an association either... > > >>So for TCP we need to guess a 32 bit source IP address of an existing >>peer and a 16 bit port number of an existing peer... This yeilds at most >>48 bits of protection. I say at most due to the fact that the port space is >>probably smaller since it is a pretty good bet the src is a dynamic port >>which may have a more limited range... i.e. figure out what TCP port >>range, dynamically, windows uses and this narrows the bits some.. >> >>Conclusion - TCP provides 48 bits of protection, at most, against >> blind attacks. >> >>Now for SCTP-addr we need to guess the same 48 bits again but >>we add to this a 32 bit V-tag. And in this 32 bit V-tag you must >>guess the single one (no matter how many associations are up >>on the machine) that goes with the pariticular source address and >>port of the victim's peer. This means you get the same 48 bits PLUS >>a full additional 32 bits of protection so: >> >>Conclusion SCTP-addr provides 80 bits of protection (at most for >>the same discussion of the port issue I made in TCP) against blind >>attacks. >> >>Now for SCTP-vtag - Here we blindly take any valid V-tag that >>is in the system on any active association.. we don't care what the >>addresses are.. all we look at is the V-tag and destination port. The >>destination port is, as we discussed, easily guessable.. so we can >>dis-qualify that. Instead we have a N in 32bit chance of getting >>a packet accepted.. where N is the number of active associations >>up on the machine. >> >>Conclusion SCTP-vtag provides less than 32 bits of protection >>against blind attack's being substantially weaker than even >>plain old TCP. >> >>Another interesting side note is that SCTP depends on the V-tag >>to also filter out mis-routed packets as well.. (TCP uses a pseudo >>header in the checksum for this purpose) A mis-routed packet >>has less than a 1 in 4billion chance of being accepted by SCTP-addr >>since the mis-routed packet must also have a source/dest port that matches >>an existing association and the complete V-Tag space is available >>you have a 1 in the full 32 bits of getting the mis-routed packet through.. >>i.e. the same 80bit protection is afforded.. >> >>SCTP-vtag on the other hand, only has to have the destination port >>match any existing destination port and then you get a N in 32 bit >>chance of getting the mis-routed packet through.. >> >>So: What can you do to protect yourself if you are using this >>implementation? >> >>Make sure SCTP_SLOW_VERIFICATION is defined in your build. This will change >>the code to do: >> >>#define sctp_match_vtag(__sp, __saddr, __daddr, __v_tag, __sport, __dport) \ >> ( ((__v_tag) == (__sp)->v_tag) && \ >> ((__sport) == (__sp)->sport) && \ >> ((__dport) == (__sp)->dport) && \ >> (sctp_find_saddr((__sp),(__daddr))) && \ >> (sctp_find_daddr((__sp),(__saddr))) ) >> >>instead of the much weaker: >> >>#define sctp_match_vtag(__sp, __saddr, __daddr, __v_tag, __sport, __dport) \ >> ( ((__v_tag) == (__sp)->v_tag) && \ >> ((__sport) == (__sp)->sport) ) >> >>In finding associations. >> >> >>One dis-advantage to this approach however, is you will have to make >>sure that ALL addresses >>of the peers are known when you open a listening endpoint.. otherwise >>some of the scenarios >>discussed in the matching discussion will occcur and associations could >>fail to >>start up.. >> >> > >Associations will not fail to start up, even with the static port examples >given by Caitlin, Ivan and yourself. > Yes, there is a scenario that Ivan illustrated with colliding INIT's where unless you pre-know all the addresses on each side, the association will not startup.. Ivan painted this quite well.. as well as his most recent illustration... which for some reason you refuse to acknowledge... R > >--brian > > > >>Regards >> >>R >> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 6 10:28:27 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20269 for ; Thu, 6 Mar 2003 10:28:25 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26FG7v2008233 for ; Thu, 6 Mar 2003 07:16:07 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h26FG67w005345 for ; Thu, 6 Mar 2003 07:16:06 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h26FDfbS019822 for ; Thu, 6 Mar 2003 07:13:52 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26Elr127456 for ; Thu, 6 Mar 2003 16:47:54 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 16:47:56 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 16:47:56 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 16:47:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Address List Change on Restart Date: Thu, 6 Mar 2003 16:47:54 +0200 Message-ID: Thread-Topic: Address List Change on Restart Thread-Index: AcLj6gQBfw5Uch9KThyPeaOhqCahQwAAQ0rQ From: To: , X-OriginalArrivalTime: 06 Mar 2003 14:47:55.0912 (UTC) FILETIME=[5F864880:01C2E3EF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA20269 Hi all! > Caitlin, > > IG Section 2.6 would have you refuse the INIT with a new error > code if addresses are added. But this is not necessary if one > uses the source address of the packet rather than the source > address list. Consider the following: > > HOST A/B HOST C/D > -------- -------- > > Existing assocation (A/B:1000 <-> C/D:9999) > <==================================================> > > Attacker sends (Z:1000->C:9999, (A,B)) > -------------------------------------------> > > Section 2.6 of the IG says that HOST C/D must refuse this init. > The reason for refusing at the INIT stage instead of waiting for > COOKIE-ECHO is that if HOST C/D sends an INIT-ACK with tie tags > populated, it will be exposing both VTs of the existing > association in the tie tag (the cookie is not encrypted, only > hashed). > > However, if we look up on Z:1000,C/D:9999 (only the information > from the packet headers) we will not find the existing > association and will set tie tags to zero (0). If the attacker And create a new VT... And of course, the peer's VT is also a new one... Remember that you are treating this case as a completely new association and that the peer has restarted (so the peers VT cannot match)... > sends a COOKIE-ECHO, as it has tie tags of zero and there is an > existing association we apply Action (C) and discard the Why C? Neither VT matches, and Tie Tags are set to zero so you go to... oops! no one... Thus you discard the COOKIE ECHO... So this invalidates your whole mail... Unless, of course, I'm missing some other special trick... :-/ The peer will keep resending the COOKIE ECHO until it concludes that you are down and stops trying. Following the IG you will at least warn the peer what is the reason... giving him a chance for "rectification" (either wait for a while, or start a new association not using the "extra" addresses, and then either tear it down and start with all the addresses, or use AddIP if both ends support it)... Of course this will happen only if you check all the source addresses included in the COOKIE ECHO (so at the end you have to check anyway, and apart from it, you have recalculated twice the MAC of the State Cookie, and sent an extra datagram)... Otherwise you might end up having two associations sharing some of the pairs (source address/port, destination address/port), with unknown consequences... But of course, in your case, relying on the VT to identify the associations, will make these two associations easy to differentiate and you might even live with both of them, even though they are illegal... BR Iván Arias Rodríguez > COOKIE-ECHO and the attacker is thwarted. > > INIT-ACK (Z:1000<-C/D:9999, (D/C), tie tags 0) > <------------------------------------------- > > COOKIE-ECHO (tie tags 0) > -------------------------------------------> > Discard Action (C) > > Note that if the attacker uses address A or B as the source > address in the INIT, the INIT-ACK will be sent to A or B and > discarded there because there is no oustanding INIT with the > given verification tag. > > This approach is superior to that of IG Section 2.6 because it > permits restarts sent from existing addresses (A or B in the > example) to add addresses to the list, but thwarts the outside > attack. Also, no exhaustive searches of arbitrarily long > address lists is required (searching address lists opens one up > to other attacks). > > So, for example, > > HOST A/B HOST C/D > -------- -------- > > Existing assocation (A/B:1000 <-> C/D:9999) > <==================================================> > > HOST A/B Restarts with additional address Z. > > INIT (A:1000->C:9999, (B,Z)) > ---------------------------------------------------> > > Section 2.6 of the IG would have you refuse this INIT. If HOST > C/D looks up the association on packet header information only, > it will find the existing assocation, populate tie tags and the > restart will complete: > > INIT-ACK (A:1000<-C/D:9999, (D/C), tie tags set) > <--------------------------------------------------- > > COOKIE-ECHO (tie tags set) > ---------------------------------------------------> > Restart Action (A) > > COOKIE-ACK > <--------------------------------------------------- > > Of course if HOST A/B restarts and attempts to restart the > association with address Z as the initial primary, then the > initialization attempt will time-out in COOKIE-ECHOED state, > however, a HEARTBEAT should have destroyed the initial > assocation by that time and a simply retry by the ULP will > succeed. > > So, if you want to support hosts that restart with additional IP > addresses (quite plausible as you say), IMO you would be best to > ignore both IG Section 2.6 and IG Section 2.18. > > This is how our implementation has functioned for years now. > > --brian > > > On Wed, 05 Mar 2003, Caitlin Bestler wrote: > > > Section 10.1 (Interface with Upper Layer - ULP-to-SCTP) > > specifies: > > > > o local eligible address list - An address list that the > > local SCTP endpoint should bind. By default, if an address > > list is not included, all IP addresses assigned to the host > > should be used by the local endpoint. > > > > > > When this default is being reused, it is highly plausible > > that a restart would result in the list of IP addresses > > being different than previously. > > > > If such a system attempts to restart an association > > immediately. Is the peer required to note the changes > > in the address list during the peer restart sequence > > specified for case A (peer restart) in section 5.4.2 > > ("Handle a COOKIE ECHO when a TCB exists")? > > > > Caitlin Bestler > > http://asomi.com/CaitlinBestler/ > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > From owner-extdom.sctp-impl@sj-core-2.cisco.com Thu Mar 6 10:30:15 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20449 for ; Thu, 6 Mar 2003 10:30:13 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26FIW0N006138 for ; Thu, 6 Mar 2003 07:18:32 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h26FIVcp025174 for ; Thu, 6 Mar 2003 07:18:31 -0800 (PST) Received: from gw.openss7.com (IDENT:z0aPNH/GB4fUug6cMmFUqxW++qGrMz5a@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h26FEXbS020436 for ; Thu, 6 Mar 2003 07:14:38 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:OeTAdu26zA0Z5+QPJUdSyOrK2HJaEZSn@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h26F9wD23228; Thu, 6 Mar 2003 08:09:58 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h26F9v704896; Thu, 6 Mar 2003 08:09:57 -0700 Date: Thu, 6 Mar 2003 08:09:57 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: rrs@cisco.com, cait@asomi.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030306080957.B2588@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Thu, Mar 06, 2003 at 03:22:42PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Thu, 06 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > > Ivan.Arias-Rodriguez, > > > > On Tue, 04 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > > > Hi! > > > > > > So this is the example of INIT collision. It is the typical one, when > > > both peers start about at the same time. This is the notation used: > > > > > > - For all the chunks: > > > o In capital letters the NAME OF CHUNK. > > > o VT is the Verification Tag included in the SCTP header. > > > o Source Address:Port->Destination Address:Port. > > > > > > - For INIT and INIT ACK: > > > o IT is the Initiation Tag included in the header of the chunk. > > > > > > - For INIT ACK and COOKIE ECHO: > > > o VTloc and VTpeer are the values of the local Verification > > > Tag (the one the INIT ACK sender expects in the SCTP headers > > > of the peer) and the peer's Verification Tag (the one the INIT > > > ACK senders includes in its SCTP headers) as included in the > > > State Cookie. Note that those values are directly copied from > > > the INIT ACK and included in the COOKIE ECHO. > > > > > o TTloc and TTpeer are the values of the local Tie Tag (the > > > value of VTloc at the moment of sending the INIT ACK) and the > > > peer's Tie Tag (the value of VTpeer at the moment of sending > > > the INIT ACK) as included in the State Cookie. Note that those > > > values are directly copied from the INIT ACK and included in > > > the COOKIE ECHO. > > > > > > The TCBs are only shown when there is a change. They show: > > > - Source address/es:Source Port. > > > - Destination address/es: Destination Port. > > > - Local Verification Tag. > > > - Peers Verification Tag. > > > - State. > > > > > > Let's see the scenario. > > > > > > > > > Host A Host B/C > > > > > > TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB > > > A:1000 \ A:1000->B:1000 ?:1000->A:1000 / B,C:1000 > > > B:1000 \ / A:1000 > > > VTloc:W \ / VTloc:X > > > VTpeer:0 \ / VTpeer:0 > > > C-WAIT \ / C-WAIT > > > \--------------------\ /--------------------/ > > > \/ > > > /\ > > > / \ > > > (1) <-------------------------/ \-------------------------> > > > > > > \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:X / > > > \ A:1000->C:1000 B:1000->A:1000 / > > > \ VTloc:Y VTpeer:X VTloc:X VTpeer:W / > > > \TTloc:0 TTpeer:0 TTloc:X TTpeer:0/ > > > \ / > > > \ / > > > \--------------------\ /--------------------/ > > > \/ > > > /\ > > > / \ > > > <-------------------------/ \-------------------------> > > > > > > TCB \ COOKIE ECHO VT:X COOKIE ECHO VT:Y / TCB > > > A:1000 \ A:1000->B:1000 C:1000->A:1000 / B,C:1000 > > > B,C:1000 \ VTloc:X VTpeer:W VTloc:Y VTpeer:W / A:1000 > > > VTloc:W \TTloc:X TTpeer:0 TTloc:0 TTpeer:0/ VTloc:X > > > VTpeer:X \ / VTpeer:Y > > > C-ECHOED \ / C-ECHOED > > > \--------------------\ /--------------------/ > > > \/ > > > /\ > > > / \ > > > (2) X<-------------------------/ \-------------------------> (3) > > > > > > COOKIE ACK VT:W / TCB > > > / B,C:1000 > > > / A:1000 > > > / VTloc:X > > > / VTpeer:W > > > / ESTABLISH > > > /--------------------/ > > > / > > > / > > > / > > > (4) X<-------------------------/ > > > > > > > > > > > > Some remarks: > > > > > > (1) At this point, Host A doesn't recognize the INIT as coming from > > > the same association it is trying to establish. The VT is completely > > > different. Thus, it goes in the normal (and wrong) establishment > > > procedure, creates a new IT and set the Tie Tags to 0. > > > > > > (2) The received COOKIE ECHO is discarded, since the VT is wrong (Host > > > A is expecting VT set to W). > > > > > > (3) Host B,C recognizes the collision due to the Tie Tags, recognize > > > it as situation B of section 5.2.4 and updates the VTpeer to W. > > > > > > (4) The COOKIE ACK is discarded, since Host A is in the C-ECHOED state. COOKIE-ACKs are not discarded in C-ECHOED state. The association will form. > > > > > > > > > And now? > > > > > > Host A will retransmit the COOKIE ECHO, Host B,C will answer again, > > > and the COOKIE ACK is discarded again. > > > > > > Conclusion: Host A cannot establish an association with Host B,C in > > > this situation. > > > > > > Brian, did I make any mistake? I hope I didn't... :-/ > > My mistake... Please ignore previous remarks. Our implementation can both generate and resolve collisions. Walking through the code, let me describe what happens above, assuming first our implementation is Host A. At (1) Host A will look for listening sockets/streams. As there is none, it will check the TCB hashes with lookup by port and address pair from the IP and SCTP headers. If (as I believe you have drawn the diagram) the INIT from Host B/C has a source address of C, this lookup will fail. The INIT will be treated as Out of the Blue and discarded. So, the INIT-ACK and from HOST A at (1) will not occur. Which is good, because the COOKIE-ECHO would have ultimately been discarded. When Host A receives the INIT-ACK it looks up the socket/stream by verification tag from the VT hashes and sends the COOKIE-ECHO. (2) will not occur because Host A did not send an INIT-ACK. At (3) when Host B/C receives the COOKIE-ECHO with tie tags it will update VTpeer to W and send the cookie ack. When Host A receives the COOKIE-ACK the association is established. When we are Host B/C: When we receive Host A's INIT we will look for a listening socket/stream and find none. We will then look up in TCB hashes (port pair and address pair) and find the socket/stream that launched the INIT. We will populate tie tags and send the COOKIE-ECHO as described. When we receive the INIT-ACK we look up the socket by VT in the VT hashes and send the COOKIE-ECHO as you have shown. If we receive Host A's COOKIE-ECHO we look up the socket by VT in the VT hashes because there are no tie tags and find the TCB. We perform action B because of the population of tie tags. Because we are in the COOKIE-ECHOED state we cancel our cookie timer and send a COOKIE-ACK as shown. The association forms if we are Host A, or Host B/C, or both Host A and Host B/C. We never looked in the source address list to find the TCB. We did not need to know the addresses of the peer in advance. This case does not require examining the addresses in the source address list. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-2.cisco.com Thu Mar 6 11:05:56 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22802 for ; Thu, 6 Mar 2003 11:05:54 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26Fx70N006260 for ; Thu, 6 Mar 2003 07:59:07 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h26Fx7cp012110 for ; Thu, 6 Mar 2003 07:59:07 -0800 (PST) Received: from gw.openss7.com (IDENT:OPYyOsBxldWHj/lF0RGv/MF3oT+1jBOq@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h26FtObS028984 for ; Thu, 6 Mar 2003 07:55:27 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:veTy3ATXcAJJGSKBcS4Pp142YS3Ii/lZ@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h26FnsD23920; Thu, 6 Mar 2003 08:49:54 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h26Fnsp05851; Thu, 6 Mar 2003 08:49:54 -0700 Date: Thu, 6 Mar 2003 08:49:54 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart Message-ID: <20030306084954.C2588@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Thu, Mar 06, 2003 at 04:47:54PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Thu, 06 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Hi all! > > > Caitlin, > > > > IG Section 2.6 would have you refuse the INIT with a new error > > code if addresses are added. But this is not necessary if one > > uses the source address of the packet rather than the source > > address list. Consider the following: > > > > HOST A/B HOST C/D > > -------- -------- > > > > Existing assocation (A/B:1000 <-> C/D:9999) > > <==================================================> > > > > Attacker sends (Z:1000->C:9999, (A,B)) > > -------------------------------------------> > > > > Section 2.6 of the IG says that HOST C/D must refuse this init. > > The reason for refusing at the INIT stage instead of waiting for > > COOKIE-ECHO is that if HOST C/D sends an INIT-ACK with tie tags > > populated, it will be exposing both VTs of the existing > > association in the tie tag (the cookie is not encrypted, only > > hashed). > > > > However, if we look up on Z:1000,C/D:9999 (only the information > > from the packet headers) we will not find the existing > > association and will set tie tags to zero (0). If the attacker > > And create a new VT... And of course, the peer's VT is also a new > one... Remember that you are treating this case as a completely new > association and that the peer has restarted (so the peers VT cannot > match)... I am assuming that I have a listening socket on C:9999. Our implementation looks for a listening socket/stream. If there is no listening socket/stream it looks for a TCB match on IP/SCTP header information (which will not find the existing association) and the INIT would then be treated as out of the blue. So either a new VT is selected and sent, or the INIT is discarded. > > > sends a COOKIE-ECHO, as it has tie tags of zero and there is an > > existing association we apply Action (C) and discard the > > Why C? Neither VT matches, and Tie Tags are set to zero so you go > to... oops! no one... Thus you discard the COOKIE ECHO... So this > invalidates your whole mail... Unless, of course, I'm missing some > other special trick... :-/ Sorry, not C, but D. Our implementation performs Action D, however, it does not send the COOKIE-ACK. The passive open attempt is queued to the listening socket. When an accept() is performed on the listening socket, the connection attempt is checked for conflicts before being placed into the TCB hashes. (I.e. a TCB doesn't exist yet.) This COOKIE-ECHO will fail the conflict check as an existing association conflicts with the association that would be established. At this time the COOKIE-ECHO is discarded and no COOKIE-ACK is sent in response. > > The peer will keep resending the COOKIE ECHO until it concludes that > you are down and stops trying. Following the IG you will at least warn > the peer what is the reason... giving him a chance for "rectification" > (either wait for a while, or start a new association not using the > "extra" addresses, and then either tear it down and start with all the > addresses, or use AddIP if both ends support it)... The attacker gets ETIMEDOUT, which is good. The non-attacker using a source address in the INIT that is within the addresses in the current association will succeed on the restart where the IG would have you fail that connection indefinitely for users that simply bind with INADDR_ANY. > > Of course this will happen only if you check all the source addresses > included in the COOKIE ECHO (so at the end you have to check anyway, I never use the source address lists "[w]hen searching for the TCB" which is what the IG foolishly says. After the TCB is found, I search for conflicts using the source address list on COOKIE-ECHO, but never on INIT or INIT-ACK as the IG states. > and apart from it, you have recalculated twice the MAC of the State > Cookie, and sent an extra datagram)... I did not send an extra datagram, the attacker did. The cost of calculating the MAC (which is almost always necessary) is less than searching for conficts "[w]hen searching for the TCB" (which is never necessary). This is because I would have to lock the hashes while searching recursively for conflicts on arbitrarily long address lists on each INIT or INIT-ACK or COOKIE-ECHO if conflicts where checked "[w]hen searching for the TCB". MAC calculations run without locks. > Otherwise you might end up > having two associations sharing some of the pairs (source > address/port, destination address/port), with unknown consequences... The only requirement is that two associations not be ESTABLISHED. This is best determined at receipt of COOKIE-ECHO and checking for conflicts before moving the association to the ESTABLISHED state. > But of course, in your case, relying on the VT to identify the > associations, will make these two associations easy to differentiate > and you might even live with both of them, even though they are > illegal... We only ever have 1 association between endpoints because a conflict check is made before the association is moved to the ESTABLISHED state. --brian > > BR Iván Arias Rodríguez > > > COOKIE-ECHO and the attacker is thwarted. > > > > INIT-ACK (Z:1000<-C/D:9999, (D/C), tie tags 0) > > <------------------------------------------- > > > > COOKIE-ECHO (tie tags 0) > > -------------------------------------------> > > Discard Action (C) > > > > Note that if the attacker uses address A or B as the source > > address in the INIT, the INIT-ACK will be sent to A or B and > > discarded there because there is no oustanding INIT with the > > given verification tag. > > > > This approach is superior to that of IG Section 2.6 because it > > permits restarts sent from existing addresses (A or B in the > > example) to add addresses to the list, but thwarts the outside > > attack. Also, no exhaustive searches of arbitrarily long > > address lists is required (searching address lists opens one up > > to other attacks). > > > > So, for example, > > > > HOST A/B HOST C/D > > -------- -------- > > > > Existing assocation (A/B:1000 <-> C/D:9999) > > <==================================================> > > > > HOST A/B Restarts with additional address Z. > > > > INIT (A:1000->C:9999, (B,Z)) > > ---------------------------------------------------> > > > > Section 2.6 of the IG would have you refuse this INIT. If HOST > > C/D looks up the association on packet header information only, > > it will find the existing assocation, populate tie tags and the > > restart will complete: > > > > INIT-ACK (A:1000<-C/D:9999, (D/C), tie tags set) > > <--------------------------------------------------- > > > > COOKIE-ECHO (tie tags set) > > ---------------------------------------------------> > > Restart Action (A) > > > > COOKIE-ACK > > <--------------------------------------------------- > > > > Of course if HOST A/B restarts and attempts to restart the > > association with address Z as the initial primary, then the > > initialization attempt will time-out in COOKIE-ECHOED state, > > however, a HEARTBEAT should have destroyed the initial > > assocation by that time and a simply retry by the ULP will > > succeed. > > > > So, if you want to support hosts that restart with additional IP > > addresses (quite plausible as you say), IMO you would be best to > > ignore both IG Section 2.6 and IG Section 2.18. > > > > This is how our implementation has functioned for years now. > > > > --brian > > > > > > On Wed, 05 Mar 2003, Caitlin Bestler wrote: > > > > > Section 10.1 (Interface with Upper Layer - ULP-to-SCTP) > > > specifies: > > > > > > o local eligible address list - An address list that the > > > local SCTP endpoint should bind. By default, if an address > > > list is not included, all IP addresses assigned to the host > > > should be used by the local endpoint. > > > > > > > > > When this default is being reused, it is highly plausible > > > that a restart would result in the list of IP addresses > > > being different than previously. > > > > > > If such a system attempts to restart an association > > > immediately. Is the peer required to note the changes > > > in the address list during the peer restart sequence > > > specified for case A (peer restart) in section 5.4.2 > > > ("Handle a COOKIE ECHO when a TCB exists")? > > > > > > Caitlin Bestler > > > http://asomi.com/CaitlinBestler/ > > > > -- > > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > > ¦ Therefore all progress depends on the ¦ > > ¦ unreasonable man. -- George Bernard Shaw ¦ > > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-2.cisco.com Thu Mar 6 11:31:08 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25199 for ; Thu, 6 Mar 2003 11:31:05 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26GMT0N010720 for ; Thu, 6 Mar 2003 08:22:29 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h26GLoYg013791 for ; Thu, 6 Mar 2003 08:21:50 -0800 (PST) Received: from gw.openss7.com (IDENT:b7MFaTtb4/5+4qRzM1WVkYgH9Ov/aoM9@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h26GIXbS020108 for ; Thu, 6 Mar 2003 08:18:38 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:RNy3OqbvETgmBElidJGCCCyB8YszvLkp@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h26GE4D24434; Thu, 6 Mar 2003 09:14:04 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h26GE4906687; Thu, 6 Mar 2003 09:14:04 -0700 Date: Thu, 6 Mar 2003 09:14:04 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: sctp-impl@external.cisco.com Subject: Re: Security Issue for users of OpenSS7 Message-ID: <20030306091404.D2588@openss7.org> Reply-To: bidulock@openss7.org References: <20030303151206.J16782@openss7.org> <3E63DE21.3080304@cisco.com> <20030303163628.N16782@openss7.org> <3E63F37B.7040500@cisco.com> <20030303175007.A26066@openss7.org> <3E640EF5.7020108@cisco.com> <20030303233203.B32643@openss7.org> <3E673F79.1040900@cisco.com> <20030306062444.C2350@openss7.org> <3E67533F.9080302@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E67533F.9080302@cisco.com>; from rrs@cisco.com on Thu, Mar 06, 2003 at 07:55:11AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Thu, 06 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >Randall, > > > >Your warning is about 2 years behind mine: > > > > Slow Verification > > CONFIG_SCTP_SLOW_VERIFICATION > > When a message comes from an SCTP endpoint with the correct > > verification tag, it is not necessary to check whether it is from > > a correct source address to identify the SCTP association to > > which it belongs. When you say N here, source addresses are not > > checked and it is up to firewall implementations to thwart > > attackers of the verification tag. When you say Y here, you get > > RFC 2960 compliant operation, but at a great cost to SCTP > > performance. > > > >Also, see below... > > > > So, you admit that using V-Tags weakens security .. which was the > entire purpose of the V-Tag... Looking up TCBs on V-Tag does not weaken security. Once the TCB is found, the source address of the packet can then be verified before processing a packet. We do it anyway for every message to find the source address structure for reply chunks, but only after the TCB has been looked up. So I suppose the situation regarding association security is not as bad as it sounds above. Perhaps I should change the name of the define to CONFIG_SCTP_RIDICULOUSLY_SLOW_LOOKUPS For those that want unnecessarily slow lookups as the source address can be checked after the lookup anyway. In sctp_recv_msg all one needs to do is change: /* set address for reply chunks */ if (sp->daddr) { sp->caddr = sctp_find_daddr(sk, skb->nh.iph->saddr); normal(sp->caddr); } to: /* set address for reply chunks */ if (sp->daddr) { if (!(sp->caddr = sctp_find_daddr(sk, skb->nh.iph->saddr))) return (-EPROTO); } and all messages from the wrong source address will be discarded. The source port is already checked in sctp_lookup_vtag as you faithfully reproduce below. It is certainly never necessary to consider the source address _list_ in the INIT or INIT-ACK "[w]hen searching for a TCB" as IG section 2.18 foolishly states. If you (or anyone) are that worried about it you can patch your copy with the lines above and just say 'N' to CONFIG_SCTP_SLOW_VERIFICATION, err.. CONFIG_SCTP_RIDICULOUSLY_SLOW_LOOKUPS. --brian > > > > > >On Thu, 06 Mar 2003, Randall Stewart (cisco) wrote: > > > > > > > >>Users of OpenSS7.. > >> > >>I want you to pay special attention to this email and > >>understand the security issues involved in not defining the > >>variable: > >> > >>SCTP_SLOW_VERIFICATION > >> > >>See below > >> > >>Brian F. G. Bidulock wrote: > >> > >> > >> > >>>Randall, > >>> > >>>On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > >>> > >>> > >>> > >>> > >>> > >>>>Brian F. G. Bidulock wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Randall, > >>>>> > >>>>>On Mon, 03 Mar 2003, Randall Stewart (cisco) wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>1) By using the Vtags for a hash lookup you have serverly compromised > >>>> the security associated with them. I have spent a bit more time > >>>>reviewing > >>>> your code.. and basically anytime the source port and Vtag match > >>>> you ship the packet up the stream to the processing layer of your SCTP > >>>> stack. This means that if I know a port that you are likely to have a > >>>> listener , say for example we are using SCTP for http.. not to far > >>>> fetched.. and I know there will be quite some number of connections > >>>> (invision CNN or google)... then instead of having a 1 in 4 billion > >>>> chance of guessing a Vtag.. I now have a N in 4 billion chance > >>>> (where N is the number of connections you have up right now) and > >>>> even more so I don't even need to know a source address and > >>>> port you think are valid.. you don't care.. you will accept any as > >>>> long as the V-tag and destination port are correct. This is an extreme > >>>> mis-use of a security feature that works to compromise the > >>>> security put into the protocol.. I doubt that the IESG would support > >>>> such mis-use of a feature in the protocol. > >>>> > >>>> > >>>> > >>>> > >>>IP addresses are trivial to spoof. There is no security afforded in addition > >>>to the VT by adding spoofable IP addresses to the match. If you need > >>>security, I suggest you (re)read the security section of RFC 2960. ;) > >>> > >>> > >>> > >>> > >>> > >>>> > >>>> > >>>> > >>>> > >>Has Brian mentions above, anyone can spoof IP addresses.. So lets > >>consider blind attackers > >>and there needs for a moment (TCP, SCTP-with-slow-verify (address > >>matching), SCTP-vtag/port matching). > >> > >>Protocol | Needed to guess by the hacker > >>-------------------+--------------------------------------------------------------- > >> TCP | Dest IP addr, Dest Port, Src IP addr, Src Port > >> SCTP-addr | Dest IP addr, Dest Port, Src IP addr, Src Port, V-tag > >> SCTP-vtag | Dest port, Vtag > >> > >>Now For all cases, we can discard the Dest IP address and port.. this is > >>a simple to guess.. i.e. I know your IP address and KNOW you are > >>running a XXX server at Port YYY. > >> > >> > > > >Source port is a simple guess too. > > > > > Yes, as I say below... you have a limited range that dynamic ports > are assigned from... but of course you don't have to use a dynamic > port to start an association either... > > > > > > >>So for TCP we need to guess a 32 bit source IP address of an existing > >>peer and a 16 bit port number of an existing peer... This yeilds at most > >>48 bits of protection. I say at most due to the fact that the port space is > >>probably smaller since it is a pretty good bet the src is a dynamic port > >>which may have a more limited range... i.e. figure out what TCP port > >>range, dynamically, windows uses and this narrows the bits some.. > >> > >>Conclusion - TCP provides 48 bits of protection, at most, against > >> blind attacks. > >> > >>Now for SCTP-addr we need to guess the same 48 bits again but > >>we add to this a 32 bit V-tag. And in this 32 bit V-tag you must > >>guess the single one (no matter how many associations are up > >>on the machine) that goes with the pariticular source address and > >>port of the victim's peer. This means you get the same 48 bits PLUS > >>a full additional 32 bits of protection so: > >> > >>Conclusion SCTP-addr provides 80 bits of protection (at most for > >>the same discussion of the port issue I made in TCP) against blind > >>attacks. > >> > >>Now for SCTP-vtag - Here we blindly take any valid V-tag that > >>is in the system on any active association.. we don't care what the > >>addresses are.. all we look at is the V-tag and destination port. The > >>destination port is, as we discussed, easily guessable.. so we can > >>dis-qualify that. Instead we have a N in 32bit chance of getting > >>a packet accepted.. where N is the number of active associations > >>up on the machine. > >> > >>Conclusion SCTP-vtag provides less than 32 bits of protection > >>against blind attack's being substantially weaker than even > >>plain old TCP. > >> > >>Another interesting side note is that SCTP depends on the V-tag > >>to also filter out mis-routed packets as well.. (TCP uses a pseudo > >>header in the checksum for this purpose) A mis-routed packet > >>has less than a 1 in 4billion chance of being accepted by SCTP-addr > >>since the mis-routed packet must also have a source/dest port that matches > >>an existing association and the complete V-Tag space is available > >>you have a 1 in the full 32 bits of getting the mis-routed packet through.. > >>i.e. the same 80bit protection is afforded.. > >> > >>SCTP-vtag on the other hand, only has to have the destination port > >>match any existing destination port and then you get a N in 32 bit > >>chance of getting the mis-routed packet through.. > >> > >>So: What can you do to protect yourself if you are using this > >>implementation? > >> > >>Make sure SCTP_SLOW_VERIFICATION is defined in your build. This will change > >>the code to do: > >> > >>#define sctp_match_vtag(__sp, __saddr, __daddr, __v_tag, __sport, __dport) \ > >> ( ((__v_tag) == (__sp)->v_tag) && \ > >> ((__sport) == (__sp)->sport) && \ > >> ((__dport) == (__sp)->dport) && \ > >> (sctp_find_saddr((__sp),(__daddr))) && \ > >> (sctp_find_daddr((__sp),(__saddr))) ) > >> > >>instead of the much weaker: > >> > >>#define sctp_match_vtag(__sp, __saddr, __daddr, __v_tag, __sport, __dport) \ > >> ( ((__v_tag) == (__sp)->v_tag) && \ > >> ((__sport) == (__sp)->sport) ) > >> > >>In finding associations. > >> > >> > >>One dis-advantage to this approach however, is you will have to make > >>sure that ALL addresses > >>of the peers are known when you open a listening endpoint.. otherwise > >>some of the scenarios > >>discussed in the matching discussion will occcur and associations could > >>fail to > >>start up.. > >> > >> > > > >Associations will not fail to start up, even with the static port examples > >given by Caitlin, Ivan and yourself. > > > Yes, there is a scenario that Ivan illustrated with colliding INIT's > where unless > you pre-know all the addresses on each side, the association will not > startup.. > > Ivan painted this quite well.. as well as his most recent > illustration... which > for some reason you refuse to acknowledge... > > > > R > > > > > >--brian > > > > > > > >>Regards > >> > >>R > >> > >>-- > >>Randall R. Stewart > >>ITD > >>Cisco Systems Inc. > >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > >> > >> > >> > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 6 16:40:51 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14149 for ; Thu, 6 Mar 2003 16:40:50 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26LYwv2011582 for ; Thu, 6 Mar 2003 13:34:59 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h26LYJYg000497 for ; Thu, 6 Mar 2003 13:34:19 -0800 (PST) Received: from thebe.your-site.com (lists.your-site.com [140.186.45.30]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h26LWEbS013896 for ; Thu, 6 Mar 2003 13:32:22 -0800 (PST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 5EE05244E47; Thu, 6 Mar 2003 16:30:12 -0500 (EST) Date: Thu, 6 Mar 2003 15:31:45 -0600 From: Caitlin Bestler Subject: Re: Address List Change on Restart To: bidulock@openss7.org Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com X-Priority: 3 In-Reply-To: <20030306084954.C2588@openss7.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit On 3/6/03, Brian F. G. Bidulock wrote: >> and apart from it, you have recalculated twice the MAC >> of the State Cookie, and sent an extra datagram)... > >I did not send an extra datagram, the attacker did. > As should be clear from the examples cited, the source of the redundant INIT can be a host that lacks perfect knowledge of which IP address corresponds to which host for the entire IP network. It is not necessarily an attacker. And no matter how common you might think attackers are, I would submit that hosts lacking perfect knowledge of IP Address to Host mappings are far more common. Indeed an attacker might be more likely to have that information that an honest client. The point is that the client host did not have enough information to avoid sending the "redundant" INIT. The responding server has enough data to avoid sending the excess INIT-ACK. Further, sending an excess INIT-ACK on the justification that the sender of the INIT was probably some attacker anyway would seem to be inviting a denial-of-service attack. "Take THAT you vile scum, I'll flood the network with even MORE unneeded datagrams!" >The cost of calculating the MAC (which is almost always >necessary) is less than searching for conficts "[w]hen >searching for the TCB" (which is never necessary). This >is because I would have to lock the hashes while searching >recursively for conflicts on arbitrarily long address >lists on each INIT or INIT-ACK or COOKIE-ECHO if conflicts >where checked "[w]hen searching for the TCB". MAC >calculations run without locks. A well designed index, even if hashed, can be referenced without locking the entire structure. I will also point out that nobody has questioned the value of using V-TAGs to expedite searches. I believe they can especially expedite lookups within an Established Association. For optimizing performance I would generally assume that Data Chunks had better greatly outnumber INITs, INIT-ACKs or COOKIE-ECHOes. Caitlin Bestler http://asomi.com/CaitlinBestler/ From owner-extdom.sctp-impl@sj-core-2.cisco.com Thu Mar 6 17:27:57 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15889 for ; Thu, 6 Mar 2003 17:27:55 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26MJuPS011069 for ; Thu, 6 Mar 2003 14:19:57 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h26MJucp025378 for ; Thu, 6 Mar 2003 14:19:56 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h26MJYQT008879 for ; Thu, 6 Mar 2003 14:19:39 -0800 (PST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26LoB117905 for ; Thu, 6 Mar 2003 23:50:11 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 23:51:31 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 23:51:30 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 23:51:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Address List Change on Restart Date: Thu, 6 Mar 2003 23:51:10 +0200 Message-ID: Thread-Topic: Address List Change on Restart Thread-Index: AcLj+VL8AyYZ9JOfScK/iuMYSOYaoQAJu9TA From: To: Cc: X-OriginalArrivalTime: 06 Mar 2003 21:51:11.0362 (UTC) FILETIME=[80646E20:01C2E42A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA15889 Brian, > Ivan.Arias-Rodriguez, > > On Thu, 06 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > Hi all! > > > > > Caitlin, > > > > > > IG Section 2.6 would have you refuse the INIT with a new error > > > code if addresses are added. But this is not necessary if one > > > uses the source address of the packet rather than the source > > > address list. Consider the following: > > > > > > HOST A/B HOST C/D > > > -------- -------- > > > > > > Existing assocation (A/B:1000 <-> C/D:9999) > > > <==================================================> > > > > > > Attacker sends (Z:1000->C:9999, (A,B)) > > > -------------------------------------------> > > > > > > Section 2.6 of the IG says that HOST C/D must refuse this init. > > > The reason for refusing at the INIT stage instead of waiting for > > > COOKIE-ECHO is that if HOST C/D sends an INIT-ACK with tie tags > > > populated, it will be exposing both VTs of the existing > > > association in the tie tag (the cookie is not encrypted, only > > > hashed). > > > > > > However, if we look up on Z:1000,C/D:9999 (only the information > > > from the packet headers) we will not find the existing > > > association and will set tie tags to zero (0). If the attacker > > > > And create a new VT... And of course, the peer's VT is > also a new > > one... Remember that you are treating this case as a > completely new > > association and that the peer has restarted (so the > peers VT cannot > > match)... > > I am assuming that I have a listening socket on C:9999. > > Our implementation looks for a listening socket/stream. If there > is no listening socket/stream it looks for a TCB match on IP/SCTP > header information (which will not find the existing association) > and the INIT would then be treated as out of the blue. So either > a new VT is selected and sent, or the INIT is discarded. Exactly, you send back an INIT ACK chunk containing a new IT (because you couldn't find the association, right?)... Also the peer's is new, since it restarted... > > > sends a COOKIE-ECHO, as it has tie tags of zero and there is an > > > existing association we apply Action (C) and discard the > > > > Why C? Neither VT matches, and Tie Tags are set to zero > so you go > > to... oops! no one... Thus you discard the COOKIE > ECHO... So this > > invalidates your whole mail... Unless, of course, I'm > missing some > > other special trick... :-/ > > Sorry, not C, but D. Our implementation performs Action D, Why D? What am I missing? Both the local and the peer's tag don't match, and the Tie Tags are set to 0, so there isn't any row in the Table 2 of the RFC 2960 for this case. In any case, you are right, you discard the COOKIE ECHO... > however, it does > not send the COOKIE-ACK. The passive open attempt is queued > to the listening > socket. When an accept() is performed on the listening > socket, the connection > attempt is checked for conflicts before being placed into the > TCB hashes. > (I.e. a TCB doesn't exist yet.) This COOKIE-ECHO will fail > the conflict > check as an existing association conflicts with the > association that would be > established. At this time the COOKIE-ECHO is discarded and > no COOKIE-ACK > is sent in response. And then? How is the peer then able to re-establish the association? Is not that what we want? > > > > The peer will keep resending the COOKIE ECHO until it > concludes that > > you are down and stops trying. Following the IG you > will at least warn > > the peer what is the reason... giving him a chance for > "rectification" > > (either wait for a while, or start a new association > not using the > > "extra" addresses, and then either tear it down and > start with all the > > addresses, or use AddIP if both ends support it)... > > The attacker gets ETIMEDOUT, which is good. The non-attacker > using a source > address in the INIT that is within the addresses in the > current association > will succeed on the restart where the IG would have you fail > that connection > indefinitely for users that simply bind with INADDR_ANY. Since the new Error Cause will be included in the new basic specification, the peer should know what is happening and has a chance of fixing the whole thing... This may not be the best way of doing but... > > Of course this will happen only if you check all the > source addresses > > included in the COOKIE ECHO (so at the end you have to > check anyway, > > I never use the source address lists "[w]hen searching for > the TCB" which is > what the IG foolishly says. After the TCB is found, I search > for conflicts > using the source address list on COOKIE-ECHO, but never on > INIT or INIT-ACK > as the IG states. Yes, and it seems to me that due to that, in this situation you will discard the COOKIE ECHO and the peer will never be able to restart... So, if the peer sends the INIT from any of the new addresses, it might not be able to establish the association... right? BR Iván Arias Rodríguez > > and apart from it, you have recalculated twice the MAC > of the State > > Cookie, and sent an extra datagram)... > > I did not send an extra datagram, the attacker did. > > The cost of calculating the MAC (which is almost always > necessary) is less > than searching for conficts "[w]hen searching for the TCB" > (which is never > necessary). This is because I would have to lock the hashes > while searching > recursively for conflicts on arbitrarily long address lists > on each INIT or > INIT-ACK or COOKIE-ECHO if conflicts where checked "[w]hen > searching for the > TCB". MAC calculations run without locks. > > > Otherwise you might end up > > having two associations sharing some of the pairs (source > > address/port, destination address/port), with unknown > consequences... > > The only requirement is that two associations not be > ESTABLISHED. This > is best determined at receipt of COOKIE-ECHO and checking for > conflicts > before moving the association to the ESTABLISHED state. > > > But of course, in your case, relying on the VT to identify the > > associations, will make these two associations easy to > differentiate > > and you might even live with both of them, even though they are > > illegal... > > We only ever have 1 association between endpoints because a > conflict check > is made before the association is moved to the ESTABLISHED state. > > --brian > > > > > BR Iván Arias Rodríguez > > > > > COOKIE-ECHO and the attacker is thwarted. > > > > > > INIT-ACK (Z:1000<-C/D:9999, (D/C), tie tags 0) > > > <------------------------------------------- > > > > > > COOKIE-ECHO (tie tags 0) > > > -------------------------------------------> > > > Discard Action (C) > > > > > > Note that if the attacker uses address A or B as the source > > > address in the INIT, the INIT-ACK will be sent to A or B and > > > discarded there because there is no oustanding INIT with the > > > given verification tag. > > > > > > This approach is superior to that of IG Section 2.6 because it > > > permits restarts sent from existing addresses (A or B in the > > > example) to add addresses to the list, but thwarts the outside > > > attack. Also, no exhaustive searches of arbitrarily long > > > address lists is required (searching address lists opens one up > > > to other attacks). > > > > > > So, for example, > > > > > > HOST A/B HOST C/D > > > -------- -------- > > > > > > Existing assocation (A/B:1000 <-> C/D:9999) > > > <==================================================> > > > > > > HOST A/B Restarts with additional address Z. > > > > > > INIT (A:1000->C:9999, (B,Z)) > > > ---------------------------------------------------> > > > > > > Section 2.6 of the IG would have you refuse this INIT. If HOST > > > C/D looks up the association on packet header information only, > > > it will find the existing assocation, populate tie tags and the > > > restart will complete: > > > > > > INIT-ACK (A:1000<-C/D:9999, (D/C), tie tags set) > > > <--------------------------------------------------- > > > > > > COOKIE-ECHO (tie tags set) > > > ---------------------------------------------------> > > > Restart Action (A) > > > > > > COOKIE-ACK > > > <--------------------------------------------------- > > > > > > Of course if HOST A/B restarts and attempts to restart the > > > association with address Z as the initial primary, then the > > > initialization attempt will time-out in COOKIE-ECHOED state, > > > however, a HEARTBEAT should have destroyed the initial > > > assocation by that time and a simply retry by the ULP will > > > succeed. > > > > > > So, if you want to support hosts that restart with additional IP > > > addresses (quite plausible as you say), IMO you would be best to > > > ignore both IG Section 2.6 and IG Section 2.18. > > > > > > This is how our implementation has functioned for years now. > > > > > > --brian > > > > > > > > > On Wed, 05 Mar 2003, Caitlin Bestler wrote: > > > > > > > Section 10.1 (Interface with Upper Layer - ULP-to-SCTP) > > > > specifies: > > > > > > > > o local eligible address list - An address list that the > > > > local SCTP endpoint should bind. By default, if an address > > > > list is not included, all IP addresses assigned to the host > > > > should be used by the local endpoint. > > > > > > > > > > > > When this default is being reused, it is highly plausible > > > > that a restart would result in the list of IP addresses > > > > being different than previously. > > > > > > > > If such a system attempts to restart an association > > > > immediately. Is the peer required to note the changes > > > > in the address list during the peer restart sequence > > > > specified for case A (peer restart) in section 5.4.2 > > > > ("Handle a COOKIE ECHO when a TCB exists")? > > > > > > > > Caitlin Bestler > > > > http://asomi.com/CaitlinBestler/ > > > > > > -- > > > Brian F. G. Bidulock ¦ The reasonable man adapts > himself to the ¦ > > > bidulock@openss7.org ¦ world; the unreasonable one > persists in ¦ > > > http://www.openss7.org/ ¦ trying to adapt the world to > himself. ¦ > > > ¦ Therefore all progress > depends on the ¦ > > > ¦ unreasonable man. -- George > Bernard Shaw ¦ > > > > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > From owner-extdom.sctp-impl@sj-core-2.cisco.com Thu Mar 6 17:51:27 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16447 for ; Thu, 6 Mar 2003 17:51:26 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26McCPS002433; Thu, 6 Mar 2003 14:38:13 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEE87916; Thu, 6 Mar 2003 14:38:10 -0800 (PST) Message-ID: <3E67CDD1.7080504@cisco.com> Date: Thu, 06 Mar 2003 16:38:09 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Caitlin Bestler CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Caitlin Bestler wrote: >On 3/6/03, Brian F. G. Bidulock wrote: > > > >>>and apart from it, you have recalculated twice the MAC >>>of the State Cookie, and sent an extra datagram)... >>> >>> >>I did not send an extra datagram, the attacker did. >> >> >> >As should be clear from the examples cited, the source of >the redundant INIT can be a host that lacks perfect >knowledge of which IP address corresponds to which host >for the entire IP network. It is not necessarily an >attacker. And no matter how common you might think attackers >are, I would submit that hosts lacking perfect knowledge of >IP Address to Host mappings are far more common. > >Indeed an attacker might be more likely to have that >information that an honest client. > >The point is that the client host did not have enough >information to avoid sending the "redundant" INIT. The >responding server has enough data to avoid sending the >excess INIT-ACK. > >Further, sending an excess INIT-ACK on the justification >that the sender of the INIT was probably some attacker >anyway would seem to be inviting a denial-of-service attack. >"Take THAT you vile scum, I'll flood the network with even >MORE unneeded datagrams!" > > Caitlin, I just love the way you put the above :)) And of course the fact that it is true makes it even funnier :> > > >>The cost of calculating the MAC (which is almost always >>necessary) is less than searching for conficts "[w]hen >>searching for the TCB" (which is never necessary). This >>is because I would have to lock the hashes while searching >>recursively for conflicts on arbitrarily long address >>lists on each INIT or INIT-ACK or COOKIE-ECHO if conflicts >>where checked "[w]hen searching for the TCB". MAC >>calculations run without locks. >> >> > >A well designed index, even if hashed, can be referenced >without locking the entire structure. > > Yep... >I will also point out that nobody has questioned the value >of using V-TAGs to expedite searches. I believe they can >especially expedite lookups within an Established >Association. For optimizing performance I would generally >assume that Data Chunks had better greatly outnumber INITs, >INIT-ACKs or COOKIE-ECHOes. > > > > And I agree with this too. One can still use Vtags to optimize most of the lookups (valdiating the addresses as well) but I think the big thing is you really need to validate the addresses.. and once you start doing this you must look in the INIT/INIT-ACK. I am going to see if I can have a chat with Steve Bellovin on this.. and get his feedback. He may, from the security side, want some wording in the IG to NOT depend solely on the V-Tag but to be sure to validate the addresses as well. And the information Brian mentioned about firewalls is silly.. A Firewall can not protect you from this for two reasons.. a) Firewalls (ones that I am familiar with at least) do not do multi-homing aka I don't know of any inter-firewall communicaiton protocol.. Thus a firewall can only protect a singly homed site. We are not restricting our discussion to a singly homed site. b) How TCP works in a firewall is the server is listening, in comes a SYN. The server responds with a SYN-ACK and this enables the hole in the firewall. I can't say for sure how SCTP firewalls will be implemented, but if it is like TCP then the INIT-ACK will open the hole in the firewall. Note TCP also has cookies but it has not modified firewall behavior to my knowledge... So an attacker can: ----INIT--(from bogus address)-----------> ----ABORT(from bogus address, Vtag-guess-1)--------> ----ABORT(from bogus address, Vtag-guess-2)---------> and a vtag+port implementation like Brian's "Fast but dangerous" implementation will end up with associations dying all over the place.. And if the firewall does wait for the cookie the attacker might even consider using its own address, open the hole and start sending bogus packets.. Oh, and Brian your little change to this code: if ( sp->daddr ) { sp->caddr = sctp_find_daddr(sp, ((struct iphdr *)mp->b_datap->db_base)->saddr); normal( sp->caddr ); } will make INIT-ACK's from an address not listed in the TCB (of the sender of the INIT) be dropped... Since the INIT-ACK from a peers address IP-B (if the INIT was sent to IP-A and no others are yet listed in the TCB) would cause the error action and you would jetison the valid INIT-ACK.. and guess what.. your association would NOT come up.. R > > > > >Caitlin Bestler >http://asomi.com/CaitlinBestler/ > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Thu Mar 6 22:11:29 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25663 for ; Thu, 6 Mar 2003 22:11:27 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2733frX021903 for ; Thu, 6 Mar 2003 19:03:42 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h27332Yg013663 for ; Thu, 6 Mar 2003 19:03:02 -0800 (PST) Received: from gw.openss7.com (IDENT:cD0WrWSf1XEczMs7xffl2VK69DJPyJfg@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2733NQT006952 for ; Thu, 6 Mar 2003 19:03:25 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:fs6QwyVukJxJUaA6jx1elW6RVBueZlYA@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h272tbD03984; Thu, 6 Mar 2003 19:55:37 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h272taW24087; Thu, 6 Mar 2003 19:55:36 -0700 Date: Thu, 6 Mar 2003 19:55:36 -0700 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart Message-ID: <20030306195536.A23700@openss7.org> Reply-To: bidulock@openss7.org References: <20030306084954.C2588@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Thu, Mar 06, 2003 at 03:31:45PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Caitlin, On Thu, 06 Mar 2003, Caitlin Bestler wrote: > On 3/6/03, Brian F. G. Bidulock wrote: > > >> and apart from it, you have recalculated twice the MAC > >> of the State Cookie, and sent an extra datagram)... > > > >I did not send an extra datagram, the attacker did. > > > As should be clear from the examples cited, the source of > the redundant INIT can be a host that lacks perfect > knowledge of which IP address corresponds to which host > for the entire IP network. It is not necessarily an > attacker. And no matter how common you might think attackers > are, I would submit that hosts lacking perfect knowledge of > IP Address to Host mappings are far more common. > > Indeed an attacker might be more likely to have that > information that an honest client. > > The point is that the client host did not have enough > information to avoid sending the "redundant" INIT. The > responding server has enough data to avoid sending the > excess INIT-ACK. > > Further, sending an excess INIT-ACK on the justification > that the sender of the INIT was probably some attacker > anyway would seem to be inviting a denial-of-service attack. > "Take THAT you vile scum, I'll flood the network with even > MORE unneeded datagrams!" The attacker does not send an extra INIT-ACK. The attacker is invited to send an extra COOKIE-ECHO for every INIT it sends. This is just the normal process. The attacker under all other circumstances receives an INIT-ACK and is invited to send a COOKIE-ECHO. The four message handshake process of SCTP is the mechanism by which attackers are distinguished from legitimate initalizations and is also process that legitimate hosts are expected to follow. Following the process for all initialization attempts is not a problem. The serving host cannot distinguish an attacker from a legitimate host from the INIT alone. It must send and receive its cookie to determine the authenticity of the source address in the INIT packet headers. If the serving host sends an ERROR in response to an INIT, it is denying legitimate hosts along with attackers. If the serving host sends INIT-ACK and makes its decision on the echoed cookie, it has verified the source address of the sender of the INIT and can make a better informed decision. The IG 2.6 exchange is: INIT --------------------------------> ERROR <-------------------------------- Legitimate as well as attackers get the ERROR. The RFC 2960 exchange is: INIT --------------------------------> INIT-ACK <-------------------------------- COOKIE-ECHO --------------------------------> Legitimate users get COOKIE-ACK <-------------------------------- attackers (and completely misconfigured or confused applications) get no COOKIE-ACK, or could be sent the new ERROR: ERROR <-------------------------------- In general, for security sake, it is better to give an attacker no information. For example, IG 2.6 says that the addresses that are in error must be placed in the ERROR message. What this serves to do is to tell the attacker which addresses are valid and which are not: a piece of information that can then be used to escalate the attack. So what I do as an attacker is send 50 source addresses for a given port pair and attacked host destination address. The host that follows IG 2.6 will kindly oblige and send me my source address and all the addresses that are not part of the association in the ERROR response. This way I can determine which addresses belong to the association and which do not. This serves to compromise the VT strength (as Randall puts it) because I can find at least one valid source address for an association for a given port pair by interrogating the attacked host with INITs bearing the attacker's own source address. Then I can start breaking the VT by running through the VTs spoofing the now known source address until the T-bit abort sent to the spoofed host drops the association. Collecting many source addresses in this fashion, I could attack the VT in parallel, by placing the same VT and running through the VT space for all known associations for the attacked host. Oh, another piece of information you give away to an attacker in the ERROR is that an association even exists for the port pair. So, by sending INITs with my additional address I can discover which associations the attacked host have, and which it does not. (All the while forcing it to lock its TCB database during the lookup to protect TCB database integrity and eventually denying legitinate INITs while I probe.) The more secure scenario for avoiding DoS attacks and not surrendering information is to send an INIT-ACK that contains no information about existing associations in it (zero tie tags). INIT-ACKs can be created without examining the source address list of the INIT (copied verbatim to the cookie) and requires no locking. Yes HMAC calculation does occur, but without locking, and the HMAC calculation is necessary both for legitimate senders as well as attackers and is the basis upon which the two are distinguished. > > >The cost of calculating the MAC (which is almost always > >necessary) is less than searching for conficts "[w]hen > >searching for the TCB" (which is never necessary). This > >is because I would have to lock the hashes while searching > >recursively for conflicts on arbitrarily long address > >lists on each INIT or INIT-ACK or COOKIE-ECHO if conflicts > >where checked "[w]hen searching for the TCB". MAC > >calculations run without locks. > > A well designed index, even if hashed, can be referenced > without locking the entire structure. But that is an implementation decision, and thus the mis-use of the SHOULD keyword. How an implementation searches for a TCB is its own business. RFC 2960 clearly states that no two associations can be formed between the pairing of destination transport addresses. How one searches has little to do with that. It is which associations that are actually established (move to the ESTABLISHED) state that counts. > > I will also point out that nobody has questioned the value > of using V-TAGs to expedite searches. I believe they can > especially expedite lookups within an Established > Association. For optimizing performance I would generally > assume that Data Chunks had better greatly outnumber INITs, > INIT-ACKs or COOKIE-ECHOes. Nobody has presumed to tell implementers how then SHOULD look for TCB for any message other than INIT or INIT-ACK (yet). It is as inappropriate to say how TCB SHOULD be searched for INIT and INIT-ACK as it is for the rest of the the messages. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 6 22:49:33 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26270 for ; Thu, 6 Mar 2003 22:49:31 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h273X4v2003584 for ; Thu, 6 Mar 2003 19:33:04 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h273X47w004182 for ; Thu, 6 Mar 2003 19:33:04 -0800 (PST) Received: from gw.openss7.com (IDENT:TM+G49Jqp4YuqYg3hbYko33r+rjKJe/s@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h273V8bS015568 for ; Thu, 6 Mar 2003 19:31:09 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:Ty2TK3bjZQ6cLCfeoaLT/Mb6uKtcZet2@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h273PlD04556; Thu, 6 Mar 2003 20:25:47 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h273Plm24595; Thu, 6 Mar 2003 20:25:47 -0700 Date: Thu, 6 Mar 2003 20:25:46 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart Message-ID: <20030306202546.B23700@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Thu, Mar 06, 2003 at 11:51:10PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Thu, 06 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > > Ivan.Arias-Rodriguez, > > > > On Thu, 06 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > > > Hi all! > > > > > > > Caitlin, > > > > > > > > IG Section 2.6 would have you refuse the INIT with a new error > > > > code if addresses are added. But this is not necessary if one > > > > uses the source address of the packet rather than the source > > > > address list. Consider the following: > > > > > > > > HOST A/B HOST C/D > > > > -------- -------- > > > > > > > > Existing assocation (A/B:1000 <-> C/D:9999) > > > > <==================================================> > > > > > > > > Attacker sends (Z:1000->C:9999, (A,B)) > > > > -------------------------------------------> > > > > > > > > Section 2.6 of the IG says that HOST C/D must refuse this init. > > > > The reason for refusing at the INIT stage instead of waiting for > > > > COOKIE-ECHO is that if HOST C/D sends an INIT-ACK with tie tags > > > > populated, it will be exposing both VTs of the existing > > > > association in the tie tag (the cookie is not encrypted, only > > > > hashed). > > > > > > > > However, if we look up on Z:1000,C/D:9999 (only the information > > > > from the packet headers) we will not find the existing > > > > association and will set tie tags to zero (0). If the attacker > > > > > > And create a new VT... And of course, the peer's VT is > > also a new > > > one... Remember that you are treating this case as a > > completely new > > > association and that the peer has restarted (so the > > peers VT cannot > > > match)... > > > > I am assuming that I have a listening socket on C:9999. > > > > Our implementation looks for a listening socket/stream. If there > > is no listening socket/stream it looks for a TCB match on IP/SCTP > > header information (which will not find the existing association) > > and the INIT would then be treated as out of the blue. So either > > a new VT is selected and sent, or the INIT is discarded. > > Exactly, you send back an INIT ACK chunk containing a new IT (because > you couldn't find the association, right?)... Also the peer's is new, > since it restarted... > > > > > sends a COOKIE-ECHO, as it has tie tags of zero and there is an > > > > existing association we apply Action (C) and discard the > > > > > > Why C? Neither VT matches, and Tie Tags are set to zero > > so you go > > > to... oops! no one... Thus you discard the COOKIE > > ECHO... So this > > > invalidates your whole mail... Unless, of course, I'm > > missing some > > > other special trick... :-/ > > > > Sorry, not C, but D. Our implementation performs Action D, > > Why D? What am I missing? Both the local and the peer's tag don't > match, and the Tie Tags are set to 0, so there isn't any row in the > Table 2 of the RFC 2960 for this case. Table 2 is only for when a TCB exists. No TCB is found so the response to the COOKIE-ECHO is the same as if no TCB existed, which also happens to be the same as Action (D) in the Table 2. > > In any case, you are right, you discard the COOKIE ECHO... > > > however, it does > > not send the COOKIE-ACK. The passive open attempt is queued > > to the listening > > socket. When an accept() is performed on the listening > > socket, the connection > > attempt is checked for conflicts before being placed into the > > TCB hashes. > > (I.e. a TCB doesn't exist yet.) This COOKIE-ECHO will fail > > the conflict > > check as an existing association conflicts with the > > association that would be > > established. At this time the COOKIE-ECHO is discarded and > > no COOKIE-ACK > > is sent in response. > > And then? How is the peer then able to re-establish the association? > Is not that what we want? It will retry the COOKIE-ECHO until it times out. If the sender of COOKIE-ECHO is an attacker, they will time out and never receive a COOKIE-ACK while the existing association remains. If the sender is legitimately the host restarting, a HEARTBEAT will abort the existing association (30 seconds) before the Cookie expires (60 seconds plus cookie preservative) and the association will be formed. This actually works quite well: the attacker gets dead air, the legitimate host, even with an INIT with a poorly chosen source address on a static allocated port pair (I don't know how that would even happen in practice will connect. This is far preferable to refusing the the INIT, surrending information about active associations and their source addresses to attackers, barring legitimate hosts and expecting their user programs to be written to be able to recover once given the information that the ULP couldn't get right in the first place. > > > > > > > The peer will keep resending the COOKIE ECHO until it > > concludes that > > > you are down and stops trying. Following the IG you > > will at least warn > > > the peer what is the reason... giving him a chance for > > "rectification" > > > (either wait for a while, or start a new association > > not using the > > > "extra" addresses, and then either tear it down and > > start with all the > > > addresses, or use AddIP if both ends support it)... > > > > The attacker gets ETIMEDOUT, which is good. The non-attacker > > using a source > > address in the INIT that is within the addresses in the > > current association > > will succeed on the restart where the IG would have you fail > > that connection > > indefinitely for users that simply bind with INADDR_ANY. > > Since the new Error Cause will be included in the new basic > specification, the peer should know what is happening and has a chance > of fixing the whole thing... This may not be the best way of doing > but... Yes, it also tells the attacker which addresses it sent in the INIT for part of the association and which do not. This is far too much information to give to hand out to an attacker. > > > > Of course this will happen only if you check all the > > source addresses > > > included in the COOKIE ECHO (so at the end you have to > > check anyway, > > > > I never use the source address lists "[w]hen searching for > > the TCB" which is > > what the IG foolishly says. After the TCB is found, I search > > for conflicts > > using the source address list on COOKIE-ECHO, but never on > > INIT or INIT-ACK > > as the IG states. > > Yes, and it seems to me that due to that, in this situation you will > discard the COOKIE ECHO and the peer will never be able to restart... > So, if the peer sends the INIT from any of the new addresses, it might > not be able to establish the association... right? It will establish the association for legitimate restarts, because if it is a legitmate restart the HEARTBEAT (or DATA or SACK) will drop the existing association before the cookie expires. With recommended protocol parameters, the existing association will be dropped own its own before the connect() times out. If an implementation sets its time outs too low, then it can always expect to have to retry, even in normal circumstances, and will retry in this circumstance as well. There is even a way that I could force the existing association down. That is to issue a HEARTBEAT on the conflicting association when discarding the COOKIE-ECHO. If it is a legitimate restart, an should ABORT be received before the COOKIE-ECHO is resent. But I think it wouldn't be worth the effort. The normal heartbeat interval should suffice. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 6 23:13:15 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26705 for ; Thu, 6 Mar 2003 23:13:14 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2742Dv2023951 for ; Thu, 6 Mar 2003 20:02:14 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2742C7w018131 for ; Thu, 6 Mar 2003 20:02:12 -0800 (PST) Received: from gw.openss7.com (IDENT:kJ96iUHOkJu1u6aRplX4prZO4PsXa/GB@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2742P1S024552 for ; Thu, 6 Mar 2003 20:02:27 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:aosZsfkMmz3ZxeDeOqSyrrv9CFpKan6+@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h273scD05001; Thu, 6 Mar 2003 20:54:38 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h273sbr24828; Thu, 6 Mar 2003 20:54:37 -0700 Date: Thu, 6 Mar 2003 20:54:37 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Caitlin Bestler , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart Message-ID: <20030306205437.C23700@openss7.org> Reply-To: bidulock@openss7.org References: <3E67CDD1.7080504@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E67CDD1.7080504@cisco.com>; from rrs@cisco.com on Thu, Mar 06, 2003 at 04:38:09PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Thu, 06 Mar 2003, Randall Stewart (cisco) wrote: > > > And I agree with this too. One can still use Vtags to optimize > most of the lookups (valdiating the addresses as well) but I think > the big thing is you really need to validate the addresses.. and once > you start doing this you must look in the INIT/INIT-ACK. > > I am going to see if I can have a chat with Steve Bellovin on this.. and get > his feedback. He may, from the security side, want some wording in > the IG to NOT depend solely on the V-Tag but to be sure to > validate the addresses as well. That would not bother me. I will still look up on VTag and don't need to examine the source address list in INIT or INIT-ACK when doing so. I will validate the source address in the packet against the TCB once the TCB is found. But I don't need the source address list to find TCBs as IG 2.18 foolishly recommends. Also if IG 2.6 stands, you will be handing the attacker the valid source address list in the ERROR and also telling the attacker which associations exist and which do not. So any checking of source addresses will be moot as the attacker a can always find a valid source address by issuing an INIT with its own IP address and an arbitrarily long list of guesses. So please have Steve consider the security ramifications of exposing information in the ERROR message of IG 2.6. As a general rule an implementation should never send any information when refusing an INIT outside of the scope of the INIT itself (parameter errors, etc). Any information given when refusing an INIT is handling information to an attacker. In the case of IG 2.6, valid and invalid addresses are identified for a port pair and the attacker is told when a port pair has an existing association and when it doesn't. Offering this information is quite naive. > > And the information Brian mentioned about firewalls is silly.. > A Firewall can not protect you from this for two reasons.. > > a) Firewalls (ones that I am familiar with at least) do not do > multi-homing aka > I don't know of any inter-firewall communicaiton protocol.. Thus a > firewall can only protect a singly homed site. We are not restricting > our discussion to a singly homed site. > > b) How TCP works in a firewall is the server is listening, in comes a > SYN. The > server responds with a SYN-ACK and this enables the hole in the > firewall. I > can't say for sure how SCTP firewalls will be implemented, but if it > is like > TCP then the INIT-ACK will open the hole in the firewall. Note TCP also > has cookies but it has not modified firewall behavior to my > knowledge... So an attacker can: Firewalls can be set up so that no SCTP packet can make it to the server from an external attacker. If you need advise on setting up firewalls for security there are some good books on the market. ;) > > ----INIT--(from bogus address)-----------> > > ----ABORT(from bogus address, Vtag-guess-1)--------> > ----ABORT(from bogus address, Vtag-guess-2)---------> Section 2.6 of the IG will tell the attacker the valid source addresses and identify existing associations so that the attacker can use this approach on all your associations with valid source addresses (without wasting their time on associations that do not exist). Unfortunately 2.6 offers the attacker the mechanism for discovering source addresses that you said was so difficult for an attacker to do in your last security analysis e-mail. With IG 2.6, finding the a valid source address for a given association is quite easy: just send an INIT from your own address with a list of all your guesses for the port pair in the source address list. The ABORT/ERROR will tell you whether an association exists for the port pair with any of the addresses provided, and will even nicely tell you which address are invalid (leaving only the valid ones). With some IP tree searching approaches used by viruses today, one could query a hosts entire TCB database in short order and then start the attacks. 2.6 is really a bad idea, and 2.18 is simply unnecessary. > > and a vtag+port implementation like Brian's "Fast but dangerous" > implementation will > end up with associations dying all over the place.. > > And if the firewall does wait for the cookie the attacker might even > consider > using its own address, open the hole and start sending bogus packets.. > > Oh, and Brian your little change to this code: > > if ( sp->daddr ) { > sp->caddr = sctp_find_daddr(sp, ((struct iphdr > *)mp->b_datap->db_base)->saddr); > normal( sp->caddr ); > } > > will make INIT-ACK's from an address not listed in the TCB (of the > sender of the > INIT) be dropped... Since the INIT-ACK from a peers address IP-B (if > the INIT > was sent to IP-A and no others are yet listed in the TCB) would cause the > error action and you would jetison the valid INIT-ACK.. and guess > what.. your association would NOT come up.. Your welcome to skip it for INIT-ACKs. (It has a GPL license so you are allowed to change your copy... But it still doesn't need to look into source address lists and lookups most things with a tag on tag.) --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Fri Mar 7 00:01:18 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27913 for ; Fri, 7 Mar 2003 00:01:17 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h274tqv2001854 for ; Thu, 6 Mar 2003 20:56:13 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h274t8Yg009128 for ; Thu, 6 Mar 2003 20:55:13 -0800 (PST) Received: from india.mercurykr.com (ptil-59-162-ind.primus-india.net [203.196.162.59] (may be forged)) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h274rRbS001174 for ; Thu, 6 Mar 2003 20:53:53 -0800 (PST) Received: from vijay (ptil-29-162-ind.primus-india.net [203.196.162.29] (may be forged)) by india.mercurykr.com (8.11.2/8.11.2) with SMTP id h279tNO10802 for ; Fri, 7 Mar 2003 15:25:24 +0530 MIME-Version: 1.0 Message-Id: <3E6823C2.000003.86107@vijay.india.mercurykr.com> Date: Fri, 7 Mar 2003 10:14:50 +0530 (India Standard Time) Content-Type: Text/Plain X-Mailer: IncrediMail 2001 (1500245) From: "Vijay Kumar Choudhary" X-Priority: 3 X-FID: FLAVOR00-NONE-0000-0000-000000000000 To: Subject: Zero Window Probe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA27913 Hi All, This mail is regarding the ZERO WINDOW PROBE. In the SCTP Imp guide version 7 some new text has been added. It says " Note that zero window probe SHOULD only be sent when all outstanding DATA chunks have been cumulatively acknowledged and no DATA chunk(s) are in flight." I dont understand one thing how is it possible that all the "outstanding DATA chunks have been cumulatively acknowledged and no DATA chunk(s) are in flight" and still the peer receiver window is 0. We also update the Peer Receiver Window at the sending side. If all the outstanding DATA chunks has been acknowledged and there is no data in the flight, we set the Peer Receiver Window to the value which we get at the time of assciation startup. Regards, Vijay From owner-extdom.sctp-impl@sj-core-1.cisco.com Fri Mar 7 00:28:52 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29942 for ; Fri, 7 Mar 2003 00:28:51 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h275NWv2021834 for ; Thu, 6 Mar 2003 21:23:32 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h275NW7w027467 for ; Thu, 6 Mar 2003 21:23:32 -0800 (PST) Received: from gw.openss7.com (IDENT:nYt4xY96Tawni/2ZQGbg5pCbRHAZbDwb@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h275NIQT005219 for ; Thu, 6 Mar 2003 21:23:20 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:UwfbOtyf5JlPxDeJwHE1DZOQYQWrBtKG@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h275GED07044; Thu, 6 Mar 2003 22:16:14 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h275GEq25832; Thu, 6 Mar 2003 22:16:14 -0700 Date: Thu, 6 Mar 2003 22:16:13 -0700 From: "Brian F. G. Bidulock" To: Vijay Kumar Choudhary Cc: sctp-impl@external.cisco.com Subject: Re: Zero Window Probe Message-ID: <20030306221613.E23700@openss7.org> Reply-To: bidulock@openss7.org References: <3E6823C2.000003.86107@vijay.india.mercurykr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E6823C2.000003.86107@vijay.india.mercurykr.com>; from vijay@india.mercurykr.com on Fri, Mar 07, 2003 at 10:14:50AM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Vijay, On Fri, 07 Mar 2003, Vijay Kumar Choudhary wrote: > Hi All, > This mail is regarding the ZERO WINDOW PROBE. In the SCTP Imp guide > version 7 some new text has been added. > It says " Note that zero window probe SHOULD only be sent when > all outstanding DATA chunks have been cumulatively acknowledged and no DATA > chunk(s) are in flight." > > I dont understand one thing how is it possible that all the "outstanding > DATA chunks have been cumulatively acknowledged and no DATA chunk(s) are in > flight" and still the peer receiver window is 0. Because the data has not yet been delivered to the ULP (e.g. the ULP had not requested to read it yet) although it has been acknowledged to the peer. > > We also update the Peer Receiver Window at the sending side. If all the > outstanding DATA chunks has been acknowledged and there is no data in the > flight, we set the Peer Receiver Window to the value which we get at the > time of assciation startup. That is not correct. The peer receive window should be set to the value in the last SACK that acked something, which is not ever necessarily the initial value (the receive window could have been changed after association startup) and takes into consideration how much data is buffered on the receiver (buffered data is subtracted from the window size). Also, SWS avoidance should be considered when setting the peer value received in the SACK so that the sender will not start sending very small fragments to the overall detriment of the network. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-5.cisco.com Fri Mar 7 05:55:10 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18595 for ; Fri, 7 Mar 2003 05:55:09 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h27ArMj1014999; Fri, 7 Mar 2003 02:53:23 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEF47898; Fri, 7 Mar 2003 02:53:21 -0800 (PST) Message-ID: <3E687A21.5020108@cisco.com> Date: Fri, 07 Mar 2003 04:53:21 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Caitlin Bestler , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart References: <3E67CDD1.7080504@cisco.com> <20030306205437.C23700@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: > > >Firewalls can be set up so that no SCTP packet can make it to the >server from an external attacker. If you need advise on setting up >firewalls for security there are some good books on the market. ;) > > Read quite a few already :> and even looked at some code.. can't find what you claim though... > > >Section 2.6 of the IG will tell the attacker the valid source >addresses and identify existing associations so that the attacker >can use this approach on all your associations with valid source >addresses (without wasting their time on associations that do not exist). > >Unfortunately 2.6 offers the attacker the mechanism for discovering >source addresses that you said was so difficult for an attacker to >do in your last security analysis e-mail. With IG 2.6, finding the >a valid source address for a given association is quite easy: just >send an INIT from your own address with a list of all your guesses for >the port pair in the source address list. The ABORT/ERROR will tell >you whether an association exists for the port pair with any of the >addresses provided, and will even nicely tell you which address are >invalid (leaving only the valid ones). > > Not that the error cause was my idea :-0 I would have no problem with removing it ... my idea was to just let the INIT's time-out if I remember correctly.. Figuring that the old assoc HB's would clean up the old TCB and eventually it the new would come up :> >With some IP tree searching approaches used by viruses today, one >could query a hosts entire TCB database in short order and then >start the attacks. > >2.6 is really a bad idea, and 2.18 is simply unnecessary. > > > > >>and a vtag+port implementation like Brian's "Fast but dangerous" >>implementation will >>end up with associations dying all over the place.. >> >>And if the firewall does wait for the cookie the attacker might even >>consider >>using its own address, open the hole and start sending bogus packets.. >> >>Oh, and Brian your little change to this code: >> >> if ( sp->daddr ) { >> sp->caddr = sctp_find_daddr(sp, ((struct iphdr >>*)mp->b_datap->db_base)->saddr); >> normal( sp->caddr ); >> } >> >>will make INIT-ACK's from an address not listed in the TCB (of the >>sender of the >>INIT) be dropped... Since the INIT-ACK from a peers address IP-B (if >>the INIT >>was sent to IP-A and no others are yet listed in the TCB) would cause the >>error action and you would jetison the valid INIT-ACK.. and guess >>what.. your association would NOT come up.. >> >> > >Your welcome to skip it for INIT-ACKs. > >(It has a GPL license so you are allowed to change your copy... But >it still doesn't need to look into source address lists and lookups >most things with a tag on tag.) > > I would not dream of it.. since I would never use it... there are better implementations .. the only reason I have a copy of your code is to know what arguments you are going to make.. R > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-2.cisco.com Fri Mar 7 06:26:11 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19458 for ; Fri, 7 Mar 2003 06:26:10 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h27BDi3H007109 for ; Fri, 7 Mar 2003 03:13:45 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h27BD4Yg029245 for ; Fri, 7 Mar 2003 03:13:05 -0800 (PST) Received: from gw.openss7.com (IDENT:FJIx3pNVHHVcaZQa4gXAgYa9OUO391lI@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h27BDk1S016804 for ; Fri, 7 Mar 2003 03:13:51 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:amoj8erA5PCdOPXhT6aME6oSfaVFP08t@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h27B72D13818; Fri, 7 Mar 2003 04:07:02 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h27B71032641; Fri, 7 Mar 2003 04:07:01 -0700 Date: Fri, 7 Mar 2003 04:07:00 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Caitlin Bestler , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart Message-ID: <20030307040700.B31104@openss7.org> Reply-To: bidulock@openss7.org References: <3E67CDD1.7080504@cisco.com> <20030306205437.C23700@openss7.org> <3E687A21.5020108@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E687A21.5020108@cisco.com>; from rrs@cisco.com on Fri, Mar 07, 2003 at 04:53:21AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Fri, 07 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > > > > > >Firewalls can be set up so that no SCTP packet can make it to the > >server from an external attacker. If you need advise on setting up > >firewalls for security there are some good books on the market. ;) > > > > > Read quite a few already :> and even looked at some code.. can't find > what you claim though... Block protocol 132 on all non-trusted interfaces. (Gee, that was simple.) > > > > > > >Section 2.6 of the IG will tell the attacker the valid source > >addresses and identify existing associations so that the attacker > >can use this approach on all your associations with valid source > >addresses (without wasting their time on associations that do not exist). > > > >Unfortunately 2.6 offers the attacker the mechanism for discovering > >source addresses that you said was so difficult for an attacker to > >do in your last security analysis e-mail. With IG 2.6, finding the > >a valid source address for a given association is quite easy: just > >send an INIT from your own address with a list of all your guesses for > >the port pair in the source address list. The ABORT/ERROR will tell > >you whether an association exists for the port pair with any of the > >addresses provided, and will even nicely tell you which address are > >invalid (leaving only the valid ones). > > > > > > Not that the error cause was my idea :-0 I would have no problem > with removing it ... my idea was to just let the INIT's time-out > if I remember correctly.. Figuring that the old assoc HB's would clean > up the old TCB and eventually it the new would come up :> Ok, so remove the error. Then I don't need to look in the source address list for 2.6 and there is no need for 2.18. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-2.cisco.com Fri Mar 7 06:44:27 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20021 for ; Fri, 7 Mar 2003 06:44:26 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h27BbF3H023118; Fri, 7 Mar 2003 03:37:16 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEF49444; Fri, 7 Mar 2003 03:37:14 -0800 (PST) Message-ID: <3E688469.3040702@cisco.com> Date: Fri, 07 Mar 2003 05:37:14 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Caitlin Bestler , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart References: <3E67CDD1.7080504@cisco.com> <20030306205437.C23700@openss7.org> <3E687A21.5020108@cisco.com> <20030307040700.B31104@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Fri, 07 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian F. G. Bidulock wrote: >> >> >> >>> >>> >>>Firewalls can be set up so that no SCTP packet can make it to the >>>server from an external attacker. If you need advise on setting up >>>firewalls for security there are some good books on the market. ;) >>> >>> >>> >>> >>Read quite a few already :> and even looked at some code.. can't find >>what you claim though... >> >> > >Block protocol 132 on all non-trusted interfaces. (Gee, that was simple.) > > How does that help you? You block 132 on non-trusted interfaces? I have two interfaces up out of my mythical firewall.. I want to accept associaitions from my peers out there.. maybe a HTTP server ... Now off these two interfaces come good INIT's etc from peers.. If I block all the interfaces I can't get any INIT's... So I guess this is the ultimate in security.. no communication good/or/bad... > > >>> >>> >>>Section 2.6 of the IG will tell the attacker the valid source >>>addresses and identify existing associations so that the attacker >>>can use this approach on all your associations with valid source >>>addresses (without wasting their time on associations that do not exist). >>> >>>Unfortunately 2.6 offers the attacker the mechanism for discovering >>>source addresses that you said was so difficult for an attacker to >>>do in your last security analysis e-mail. With IG 2.6, finding the >>>a valid source address for a given association is quite easy: just >>>send an INIT from your own address with a list of all your guesses for >>>the port pair in the source address list. The ABORT/ERROR will tell >>>you whether an association exists for the port pair with any of the >>>addresses provided, and will even nicely tell you which address are >>>invalid (leaving only the valid ones). >>> >>> >>> >>> >>Not that the error cause was my idea :-0 I would have no problem >>with removing it ... my idea was to just let the INIT's time-out >>if I remember correctly.. Figuring that the old assoc HB's would clean >>up the old TCB and eventually it the new would come up :> >> >> > >Ok, so remove the error. Then I don't need to look in the source address >list for 2.6 and there is no need for 2.18. > > 2.6 was not the reason for 2.18... Again go back and look at some of the cases laid out by Ivan and Caitlin... R >--brian > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Fri Mar 7 06:55:18 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21829 for ; Fri, 7 Mar 2003 06:55:16 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h27Bpo2s014978; Fri, 7 Mar 2003 03:51:51 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEF49903; Fri, 7 Mar 2003 03:51:49 -0800 (PST) Message-ID: <3E6887D5.9040106@cisco.com> Date: Fri, 07 Mar 2003 05:51:49 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ivan/All: I think this illustrates a point where you must search the address lists in the INIT/INIT-ACK to find the match... (Ivan I hope you don't mind me forwarding this to the list :>) Ivan.Arias-Rodriguez@nokia.com wrote: > > > > I hope I don't put my foot again in it this time... Let's see another scenario... This time both implementations are multihomed and doesn't dig into the INIT or INIT ACK to look for addresses: > >Host A/B Host C/D > >TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 >C:1000 \ / B:1000 >VTloc:W \ / VTloc:X >VTpeer:0 \ / VTpeer:0 >C-WAIT \ / C-WAIT > \--------------------\ /--------------------/ > \/ > /\ > / \ > (1) <-------------------------/ \-------------------------> > > \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:Z / > \ B:1000->D:1000 C:1000->A:1000 / > \ VTloc:Y VTpeer:X VTloc:Z VTpeer:W / > \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ > \ / > \ / > \--------------------\ /--------------------/ > \/ > /\ > / \ > <-------------------------/ \-------------------------> > >TCB \ COOKIE ECHO VT:Z COOKIE ECHO VT:Y / TCB >A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 >C,D:1000 \ VTloc:Z VTpeer:W VTloc:Y VTpeer:X / A,B:1000 >VTloc:W \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ VTloc:X >VTpeer:Z \ / VTpeer:Y >C-ECHOED \ / C-ECHOED > \--------------------\ /--------------------/ > \/ > /\ > / \ > X<-------------------------/ \------------------------->X > > > > > In the above case, using just the Vtags would never find the old association.. and even special case code would not find it (unless of course each side had complete pre-knowledge of what were the peer's addresses.. but we are talking general here and so this is NOT the case). So here we have a case where the setup of an association would fail. Note, I believe this is the case at the Bakeoff in RTP that actually generated the wording... And glancing at your code Brian, it does not work.. Those that check the INIT/INIT-ACK for addresses would find the setting up associations and populate the Tie-Tags, reusing their correct tags.. and presto the association would come up. R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Fri Mar 7 07:00:01 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22620 for ; Fri, 7 Mar 2003 06:59:58 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h27Bse2s016456; Fri, 7 Mar 2003 03:54:41 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEF49988; Fri, 7 Mar 2003 03:54:39 -0800 (PST) Message-ID: <3E68887F.7060306@cisco.com> Date: Fri, 07 Mar 2003 05:54:39 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Caitlin Bestler , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart References: <3E67CDD1.7080504@cisco.com> <20030306205437.C23700@openss7.org> <3E687A21.5020108@cisco.com> <20030307040700.B31104@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: > > >>> >>>Section 2.6 of the IG will tell the attacker the valid source >>>addresses and identify existing associations so that the attacker >>>can use this approach on all your associations with valid source >>>addresses (without wasting their time on associations that do not exist). >>> >>>Unfortunately 2.6 offers the attacker the mechanism for discovering >>>source addresses that you said was so difficult for an attacker to >>>do in your last security analysis e-mail. With IG 2.6, finding the >>>a valid source address for a given association is quite easy: just >>>send an INIT from your own address with a list of all your guesses for >>>the port pair in the source address list. The ABORT/ERROR will tell >>>you whether an association exists for the port pair with any of the >>>addresses provided, and will even nicely tell you which address are >>>invalid (leaving only the valid ones). >>> >>> >>> Thinking about this a bit more, I believe I am in agreement with something Ivan proposed (off list)... What we should do is get rid of the error cause and the abort stuff.. and instead.. the reciever of such an INIT MUST send the INIT-ACK back to one of the existing addresses... If the guy IS an attacker it does not get back the INIT-ACK and thus cannot take-over the association.. If the guy IS NOT the attacker then it gets the INIT-ACK and the association comes up... R >>> >>> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Fri Mar 7 07:53:02 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28023 for ; Fri, 7 Mar 2003 07:53:01 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h27Cikj1025942 for ; Fri, 7 Mar 2003 04:44:46 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h27Ci6Yg014625 for ; Fri, 7 Mar 2003 04:44:06 -0800 (PST) Received: from gw.openss7.com (IDENT:50slKjgK/2UXsQRzmsD6L+oKpv7QJoYV@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h27CgqbS009212 for ; Fri, 7 Mar 2003 04:42:53 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:CWj3zclh46A6gGBabrVPN7dC/XCkVEN6@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h27CXMD15616; Fri, 7 Mar 2003 05:33:22 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h27CXL702140; Fri, 7 Mar 2003 05:33:21 -0700 Date: Fri, 7 Mar 2003 05:33:21 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Caitlin Bestler , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart Message-ID: <20030307053321.C31104@openss7.org> Reply-To: bidulock@openss7.org References: <3E67CDD1.7080504@cisco.com> <20030306205437.C23700@openss7.org> <3E687A21.5020108@cisco.com> <20030307040700.B31104@openss7.org> <3E68887F.7060306@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E68887F.7060306@cisco.com>; from rrs@cisco.com on Fri, Mar 07, 2003 at 05:54:39AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Fri, 07 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > > > > > >>> > >>>Section 2.6 of the IG will tell the attacker the valid source > >>>addresses and identify existing associations so that the attacker > >>>can use this approach on all your associations with valid source > >>>addresses (without wasting their time on associations that do not exist). > >>> > >>>Unfortunately 2.6 offers the attacker the mechanism for discovering > >>>source addresses that you said was so difficult for an attacker to > >>>do in your last security analysis e-mail. With IG 2.6, finding the > >>>a valid source address for a given association is quite easy: just > >>>send an INIT from your own address with a list of all your guesses for > >>>the port pair in the source address list. The ABORT/ERROR will tell > >>>you whether an association exists for the port pair with any of the > >>>addresses provided, and will even nicely tell you which address are > >>>invalid (leaving only the valid ones). > >>> > >>> > >>> > Thinking about this a bit more, I believe I am in agreement with something > Ivan proposed (off list)... What we should do is get rid of the error cause > and the abort stuff.. and instead.. the reciever of such an INIT MUST > send the INIT-ACK back to one of the existing addresses... > > If the guy IS an attacker it does not get back the INIT-ACK and thus > cannot take-over the association.. > > If the guy IS NOT the attacker then it gets the INIT-ACK and the association > comes up... What if the existing address *is* the attacker? That is, the exsiting association is just waiting to highjack other init attempts (with a spoofed address list). Also, if the attacker does not receive an INIT-ACK (as it would in every other case) it knows that there is an association for the given port pair and that some address in the address list was correct. This opens up to scanning again. Script kiddies will love you for telling them which ports have associations and that at least one of the addresses in the address list is correct by not responding with INIT-ACK. It is a good idea to always send the INIT-ACK to the source of the INIT. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-2.cisco.com Fri Mar 7 08:30:26 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00855 for ; Fri, 7 Mar 2003 08:30:24 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h27DBv3H017807; Fri, 7 Mar 2003 05:11:57 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEF53066; Fri, 7 Mar 2003 05:11:55 -0800 (PST) Message-ID: <3E689A9B.5040306@cisco.com> Date: Fri, 07 Mar 2003 07:11:55 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Caitlin Bestler , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart References: <3E67CDD1.7080504@cisco.com> <20030306205437.C23700@openss7.org> <3E687A21.5020108@cisco.com> <20030307040700.B31104@openss7.org> <3E68887F.7060306@cisco.com> <20030307053321.C31104@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Fri, 07 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian F. G. Bidulock wrote: >> >> >> >>> >>> >>> >>> >>>>>Section 2.6 of the IG will tell the attacker the valid source >>>>>addresses and identify existing associations so that the attacker >>>>>can use this approach on all your associations with valid source >>>>>addresses (without wasting their time on associations that do not exist). >>>>> >>>>>Unfortunately 2.6 offers the attacker the mechanism for discovering >>>>>source addresses that you said was so difficult for an attacker to >>>>>do in your last security analysis e-mail. With IG 2.6, finding the >>>>>a valid source address for a given association is quite easy: just >>>>>send an INIT from your own address with a list of all your guesses for >>>>>the port pair in the source address list. The ABORT/ERROR will tell >>>>>you whether an association exists for the port pair with any of the >>>>>addresses provided, and will even nicely tell you which address are >>>>>invalid (leaving only the valid ones). >>>>> >>>>> >>>>> >>>>> >>>>> >>Thinking about this a bit more, I believe I am in agreement with something >>Ivan proposed (off list)... What we should do is get rid of the error cause >>and the abort stuff.. and instead.. the reciever of such an INIT MUST >>send the INIT-ACK back to one of the existing addresses... >> >>If the guy IS an attacker it does not get back the INIT-ACK and thus >>cannot take-over the association.. >> >>If the guy IS NOT the attacker then it gets the INIT-ACK and the association >>comes up... >> >> > >What if the existing address *is* the attacker? That is, the exsiting >association is just waiting to highjack other init attempts (with a spoofed >address list). > Hmm now the above one I don't understand from you... I have an association with an attacker Attacker <-IP-A----------------------------------------------IP-Z-> Server Are you claiming it did Atacker <-IP-A/(someother addresses)------------------------IP-Z->server and hoping for the --------------------INIT(someother address)----------> If so, two comments... a) A heartbeat that the server sends will generate an abort for some other address.. and the other addresses should be the first thing that is HB'd since the IP-A was used in setting up the assoc... So one HB delay and the attackers assoc is down. b) The attacker has to give away its valid IP address... which in combination with would yeild lots of errors pointing at him.. hopefully in a log somewhere.. generally attackers are not interested in telling you.. here is where I am at... > >Also, if the attacker does not receive an INIT-ACK (as it would in every >other case) it knows that there is an association for the given port pair >and that some address in the address list was correct. This opens up to >scanning again. Script kiddies will love you for telling them which ports >have associations and that at least one of the addresses in the address >list is correct by not responding with INIT-ACK. > > Ok, so how is this different than the attacker sending a COOKIE-ECHO---------------------> repeatedly and you discarding it? Does not the same argument apply.. of course the only difference is you have gotten to run your MD5/SHA-1 code for every COOKIE-ECHO received. Other than that.. you still have the same issue.. If I repeatedly send a COOKIE-ECHO the same clue exists... aka I have someone elses address in my list.. That is what you said you were doing in your earlier email to Caitlin? I see no difference in this.. since a valid COOKIE-ECHO always generates a COOKIE-ACK... so you have given the same information And back on the subject of fire-walls.. you missed my point.. the "trusted interfaces" that are open to INIT's are the very ones the attacker is using.. this is a server running on the Big-I serving up web pages.. all of its interfaces are trusted.. I am NOT talking sigtran.. where you have interfaces that are private... your firewall solution does not work for the Big-I R >It is a good idea to always send the INIT-ACK to the source of the INIT. > >--brian > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Fri Mar 7 08:52:36 2003 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01972 for ; Fri, 7 Mar 2003 08:52:35 -0500 (EST) Received: from sj-msg-core-1.cisco.com (171.71.163.11) by halt-in.cisco.com with ESMTP; 07 Mar 2003 05:54:48 -0800 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h27DsYJO009327 for ; Fri, 7 Mar 2003 05:54:34 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h27DkjJ6013247 for ; Fri, 7 Mar 2003 05:54:34 -0800 (PST) Received: from gw.openss7.com (IDENT:6JNTN8/5/R5eiCOD6HC5EqJzeTLlzbFZ@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h27CiB1S013651 for ; Fri, 7 Mar 2003 04:47:02 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:24/+1lqqHGt+HYg185IcEQyxtqUOWezi@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h27CbED15671; Fri, 7 Mar 2003 05:37:14 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h27CbE202235; Fri, 7 Mar 2003 05:37:14 -0700 Date: Fri, 7 Mar 2003 05:37:14 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Caitlin Bestler , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart Message-ID: <20030307053714.D31104@openss7.org> Reply-To: bidulock@openss7.org References: <3E67CDD1.7080504@cisco.com> <20030306205437.C23700@openss7.org> <3E687A21.5020108@cisco.com> <20030307040700.B31104@openss7.org> <3E688469.3040702@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E688469.3040702@cisco.com>; from rrs@cisco.com on Fri, Mar 07, 2003 at 05:37:14AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Fri, 07 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >Randall, > > > >On Fri, 07 Mar 2003, Randall Stewart (cisco) wrote: > > > > > > > >>Brian F. G. Bidulock wrote: > >> > >> > >> > >>> > >>> > >>>Firewalls can be set up so that no SCTP packet can make it to the > >>>server from an external attacker. If you need advise on setting up > >>>firewalls for security there are some good books on the market. ;) > >>> > >>> > >>> > >>> > >>Read quite a few already :> and even looked at some code.. can't find > >>what you claim though... > >> > >> > > > >Block protocol 132 on all non-trusted interfaces. (Gee, that was simple.) > > > > > How does that help you? > > You block 132 on non-trusted interfaces? I have two interfaces up out of > my mythical firewall.. I want to accept associaitions from my peers out > there.. maybe a HTTP server ... > > Now off these two interfaces come good INIT's etc from peers.. > > If I block all the interfaces I can't get any INIT's... So I guess this is > the ultimate in security.. no communication good/or/bad... I can still receive INITs on trusted interfaces. > > > > > > > > >>> > >>> > >>>Section 2.6 of the IG will tell the attacker the valid source > >>>addresses and identify existing associations so that the attacker > >>>can use this approach on all your associations with valid source > >>>addresses (without wasting their time on associations that do not exist). > >>> > >>>Unfortunately 2.6 offers the attacker the mechanism for discovering > >>>source addresses that you said was so difficult for an attacker to > >>>do in your last security analysis e-mail. With IG 2.6, finding the > >>>a valid source address for a given association is quite easy: just > >>>send an INIT from your own address with a list of all your guesses for > >>>the port pair in the source address list. The ABORT/ERROR will tell > >>>you whether an association exists for the port pair with any of the > >>>addresses provided, and will even nicely tell you which address are > >>>invalid (leaving only the valid ones). > >>> > >>> > >>> > >>> > >>Not that the error cause was my idea :-0 I would have no problem > >>with removing it ... my idea was to just let the INIT's time-out > >>if I remember correctly.. Figuring that the old assoc HB's would clean > >>up the old TCB and eventually it the new would come up :> > >> > >> > > > >Ok, so remove the error. Then I don't need to look in the source address > >list for 2.6 and there is no need for 2.18. > > > > > > 2.6 was not the reason for 2.18... Again go back and look at some of the > cases laid out by Ivan and Caitlin... I have addressed all but Ivan's recent case which I will address in just a moment. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Fri Mar 7 09:29:36 2003 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04636 for ; Fri, 7 Mar 2003 09:29:34 -0500 (EST) Received: from sj-msg-core-1.cisco.com (171.71.163.11) by halt-in.cisco.com with ESMTP; 07 Mar 2003 06:31:49 -0800 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h27EVRJO006840 for ; Fri, 7 Mar 2003 06:31:27 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h27EVQ7w008626 for ; Fri, 7 Mar 2003 06:31:26 -0800 (PST) Received: from gw.openss7.com (IDENT:M5+4EAw3OnVLMrPnwbLnMgn3yZG0NIdS@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h27EVKaG017505 for ; Fri, 7 Mar 2003 06:31:27 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:o2vp4zfrYSgXjrBhNZ+HppiiluWXcnIb@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h27ENkD17555; Fri, 7 Mar 2003 07:23:46 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h27ENkM04462; Fri, 7 Mar 2003 07:23:46 -0700 Date: Fri, 7 Mar 2003 07:23:45 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Caitlin Bestler , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart Message-ID: <20030307072345.F31104@openss7.org> Reply-To: bidulock@openss7.org References: <3E67CDD1.7080504@cisco.com> <20030306205437.C23700@openss7.org> <3E687A21.5020108@cisco.com> <20030307040700.B31104@openss7.org> <3E68887F.7060306@cisco.com> <20030307053321.C31104@openss7.org> <3E689A9B.5040306@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E689A9B.5040306@cisco.com>; from rrs@cisco.com on Fri, Mar 07, 2003 at 07:11:55AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Fri, 07 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >Randall, > > > >On Fri, 07 Mar 2003, Randall Stewart (cisco) wrote: > > > > > > > >>Brian F. G. Bidulock wrote: > >> > >> > >> > >>> > >>> > >>> > >>> > >>>>>Section 2.6 of the IG will tell the attacker the valid source > >>>>>addresses and identify existing associations so that the attacker > >>>>>can use this approach on all your associations with valid source > >>>>>addresses (without wasting their time on associations that do not exist). > >>>>> > >>>>>Unfortunately 2.6 offers the attacker the mechanism for discovering > >>>>>source addresses that you said was so difficult for an attacker to > >>>>>do in your last security analysis e-mail. With IG 2.6, finding the > >>>>>a valid source address for a given association is quite easy: just > >>>>>send an INIT from your own address with a list of all your guesses for > >>>>>the port pair in the source address list. The ABORT/ERROR will tell > >>>>>you whether an association exists for the port pair with any of the > >>>>>addresses provided, and will even nicely tell you which address are > >>>>>invalid (leaving only the valid ones). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>Thinking about this a bit more, I believe I am in agreement with something > >>Ivan proposed (off list)... What we should do is get rid of the error cause > >>and the abort stuff.. and instead.. the reciever of such an INIT MUST > >>send the INIT-ACK back to one of the existing addresses... > >> > >>If the guy IS an attacker it does not get back the INIT-ACK and thus > >>cannot take-over the association.. > >> > >>If the guy IS NOT the attacker then it gets the INIT-ACK and the association > >>comes up... > >> > >> > > > >What if the existing address *is* the attacker? That is, the exsiting > >association is just waiting to highjack other init attempts (with a spoofed > >address list). > > > > Hmm now the above one I don't understand from you... > > I have an association with an attacker > > Attacker <-IP-A----------------------------------------------IP-Z-> Server > > Are you claiming it did > > Atacker <-IP-A/(someother addresses)------------------------IP-Z->server > > and hoping for the > --------------------INIT(someother address)----------> > > If so, two comments... > > a) A heartbeat that the server sends will generate an abort for some > other address.. and the other addresses should be the first thing > that is HB'd since the IP-A was used in setting up the assoc... > So one HB delay and the attackers assoc is down. And back up again. The attacker can do this all day long. > > b) The attacker has to give away its valid IP address... which in > combination with would yeild lots of errors pointing at him.. hopefully > in a log somewhere.. generally attackers are not interested in telling you.. > here is where I am at... Do you log ABORTS? Better not, there is a DoS attack right there. > > > > > > >Also, if the attacker does not receive an INIT-ACK (as it would in every > >other case) it knows that there is an association for the given port pair > >and that some address in the address list was correct. This opens up to > >scanning again. Script kiddies will love you for telling them which ports > >have associations and that at least one of the addresses in the address > >list is correct by not responding with INIT-ACK. > > > > > Ok, so how is this different than the attacker sending a > > COOKIE-ECHO---------------------> > > repeatedly > > and you discarding it? Does not the same argument apply.. of course > the only difference is you have gotten to run your MD5/SHA-1 code > for every COOKIE-ECHO received. No. The think that gives the lack of INIT-ACK away is that is the only situation in which an INIT-ACK is not received. There are many reasons to not receive a COOKIE-ACK in response to a COOKIE-ECHO. And the attacker cannot distinguish between them. > > Other than that.. you still have the same issue.. > > If I repeatedly send a COOKIE-ECHO the same clue exists... aka > I have someone elses address in my list.. No. I am just not responding to the COOKIE-ECHO. In STREAMS I do no sent the COOKIE-ACK until the connection indication is accepted. Also, I send aborts when they are refused. > > That is what you said you were doing in your earlier email to Caitlin? Yes, I am currently discarded on conflict addresses in COOKIE-ECHO. Instead of discarding in the case of conflict, I should really send ABORT. Then the attacker will receive ABORT when there is a conflict and will receive ABORT when the connection indication is refused by the ULP. Then the attacker has no information about existing associations. Or another thought, I could send COOKIE-ACK but then kick the TCB out of the hashes so any message sent will be treated OOTB. I have many choices with COOKIE-ECHO. I have few with INIT. > > I see no difference in this.. since a valid COOKIE-ECHO always generates > a COOKIE-ACK... so you have given the same information No, I send ABORT instead of COOKIE-ACK when the connection indications is refused on listening streams in the STREAMS implemtnation. But as I said above, one could reply with COOKIE-ACK and abort any attempt to communicate on the association. > > > > And back on the subject of fire-walls.. you missed my point.. the "trusted > interfaces" that are open to INIT's are the very ones the attacker is > using.. Then they are not "trusted." > this is a server running on the Big-I serving up web pages.. all of its > interfaces are trusted.. All of its interfaces would then be "untrusted". > > I am NOT talking sigtran.. where you have interfaces that are private... > your firewall solution does not work for the Big-I Did I say it did? --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Fri Mar 7 10:15:47 2003 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10049 for ; Fri, 7 Mar 2003 10:15:46 -0500 (EST) Received: from sj-msg-core-1.cisco.com (171.71.163.11) by halt-in.cisco.com with ESMTP; 07 Mar 2003 07:18:02 -0800 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h27FHaJO000997 for ; Fri, 7 Mar 2003 07:17:36 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h27FGuYg009048 for ; Fri, 7 Mar 2003 07:16:56 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h27FFebS001974 for ; Fri, 7 Mar 2003 07:15:41 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27Ent129433 for ; Fri, 7 Mar 2003 16:49:55 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 16:51:14 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 16:51:12 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 16:51:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Fri, 7 Mar 2003 16:51:12 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLktwI88NNQffcYSLaxfyum3ngEkQAAPJnA From: To: Cc: X-OriginalArrivalTime: 07 Mar 2003 14:51:12.0477 (UTC) FILETIME=[FF1978D0:01C2E4B8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA10049 Brian, ... snip... > > > Here the TCB can be found by the destination address and > port pair in > > > the INIT: it is not necessary to look in the source > address list of > > > the INIT when searching for the TCB. > > > > ?? > > > > I don't follow you... :-/ > > > > Port are of course the same, but all what you know > about the peer at > > Host A/B is the address C. However, the INIT from Host > C/D comes from > > address D... The INIT from Host C/D effectively goes to the same > > endpoint, but seems to come from a different one (if > you don't take a > > look inside the address parameters, of course). > > > > Take into account that in this example address B > belongs now to the > > "left" endpoint... > > The INIT is sent to address B:1000. There exists a TCB with > sport=1000, > dport=1000 and saddr=B. It can be found with the port pair > and _destination_ > address of the INIT. You don't need to look at source > address at all (far > less what's in the address list). > > --brian I still don't follow you at all... What you can know is that the INIT is sent to the same endpoint, not that it comes from the same endpoint... You know it goes there, so what? You don't know where it comes from... D might or might not be part of the same endpoint that also uses C (you don't know unless you take a look to the address parameter)... What if another completely different peer sends an INIT E:1000->B:1000? will you populate the Tie Tags as well? Will you "recognize" it as being part of the association you are about the create? I simply don't understand what you are saying... It seems that the sender address doesn't count at all... :-/ BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-core-5.cisco.com Fri Mar 7 10:37:37 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11185 for ; Fri, 7 Mar 2003 10:37:35 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h27FNpgP003585; Fri, 7 Mar 2003 07:23:51 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEF58084; Fri, 7 Mar 2003 07:23:49 -0800 (PST) Message-ID: <3E68B985.1080706@cisco.com> Date: Fri, 07 Mar 2003 09:23:49 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Caitlin Bestler , Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Address List Change on Restart References: <3E67CDD1.7080504@cisco.com> <20030306205437.C23700@openss7.org> <3E687A21.5020108@cisco.com> <20030307040700.B31104@openss7.org> <3E68887F.7060306@cisco.com> <20030307053321.C31104@openss7.org> <3E689A9B.5040306@cisco.com> <20030307072345.F31104@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Fri, 07 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian F. G. Bidulock wrote: >> >> >> >>>Randall, >>> >>>On Fri, 07 Mar 2003, Randall Stewart (cisco) wrote: >>> >>> >>> >>> >>> >>>>Brian F. G. Bidulock wrote: >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>Section 2.6 of the IG will tell the attacker the valid source >>>>>>>addresses and identify existing associations so that the attacker >>>>>>>can use this approach on all your associations with valid source >>>>>>>addresses (without wasting their time on associations that do not exist). >>>>>>> >>>>>>>Unfortunately 2.6 offers the attacker the mechanism for discovering >>>>>>>source addresses that you said was so difficult for an attacker to >>>>>>>do in your last security analysis e-mail. With IG 2.6, finding the >>>>>>>a valid source address for a given association is quite easy: just >>>>>>>send an INIT from your own address with a list of all your guesses for >>>>>>>the port pair in the source address list. The ABORT/ERROR will tell >>>>>>>you whether an association exists for the port pair with any of the >>>>>>>addresses provided, and will even nicely tell you which address are >>>>>>>invalid (leaving only the valid ones). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>Thinking about this a bit more, I believe I am in agreement with something >>>>Ivan proposed (off list)... What we should do is get rid of the error cause >>>>and the abort stuff.. and instead.. the reciever of such an INIT MUST >>>>send the INIT-ACK back to one of the existing addresses... >>>> >>>>If the guy IS an attacker it does not get back the INIT-ACK and thus >>>>cannot take-over the association.. >>>> >>>>If the guy IS NOT the attacker then it gets the INIT-ACK and the association >>>>comes up... >>>> >>>> >>>> >>>> >>>What if the existing address *is* the attacker? That is, the exsiting >>>association is just waiting to highjack other init attempts (with a spoofed >>>address list). >>> >>> >>> >>Hmm now the above one I don't understand from you... >> >>I have an association with an attacker >> >>Attacker <-IP-A----------------------------------------------IP-Z-> Server >> >>Are you claiming it did >> >>Atacker <-IP-A/(someother addresses)------------------------IP-Z->server >> >>and hoping for the >> --------------------INIT(someother address)----------> >> >>If so, two comments... >> >>a) A heartbeat that the server sends will generate an abort for some >> other address.. and the other addresses should be the first thing >> that is HB'd since the IP-A was used in setting up the assoc... >> So one HB delay and the attackers assoc is down. >> >> > >And back up again. The attacker can do this all day long. > > But continued failure in the same method could be discovered.. > > >>b) The attacker has to give away its valid IP address... which in >>combination with would yeild lots of errors pointing at him.. hopefully >>in a log somewhere.. generally attackers are not interested in telling you.. >>here is where I am at... >> >> > >Do you log ABORTS? Better not, there is a DoS attack right there. > > True.. but some logging must be done somewhere or else security problems will never be found out... One could define a set of counters to figure this out without filling up the syslog > > >> >> >> >>>Also, if the attacker does not receive an INIT-ACK (as it would in every >>>other case) it knows that there is an association for the given port pair >>>and that some address in the address list was correct. This opens up to >>>scanning again. Script kiddies will love you for telling them which ports >>>have associations and that at least one of the addresses in the address >>>list is correct by not responding with INIT-ACK. >>> >>> >>> >>> >>Ok, so how is this different than the attacker sending a >> >>COOKIE-ECHO---------------------> >> >>repeatedly >> >>and you discarding it? Does not the same argument apply.. of course >>the only difference is you have gotten to run your MD5/SHA-1 code >>for every COOKIE-ECHO received. >> >> > >No. The think that gives the lack of INIT-ACK away is that is the >only situation in which an INIT-ACK is not received. > >There are many reasons to not receive a COOKIE-ACK in response to a >COOKIE-ECHO. And the attacker cannot distinguish between them. > > > Lets see.. 1) You send a ABORT if the peer is not listening anymore 2) You send a ABORT if you are out of resources 3) If the server stops accepting() that can be detected.. The evil attacker times-out, It immediately sends a normal association start.. and gets a cookie-ack and thus finds the receiver is listening... it just did not accept that association... What other reasons am I missing that you silently do a discard? R > > >>Other than that.. you still have the same issue.. >> >>If I repeatedly send a COOKIE-ECHO the same clue exists... aka >>I have someone elses address in my list.. >> >> > >No. I am just not responding to the COOKIE-ECHO. In STREAMS I do >no sent the COOKIE-ACK until the connection indication is accepted. >Also, I send aborts when they are refused. > > > >>That is what you said you were doing in your earlier email to Caitlin? >> >> > >Yes, I am currently discarded on conflict addresses in COOKIE-ECHO. > >Instead of discarding in the case of conflict, I should really send >ABORT. Then the attacker will receive ABORT when there is a conflict >and will receive ABORT when the connection indication is refused by >the ULP. Then the attacker has no information about existing >associations. > >Or another thought, I could send COOKIE-ACK but then kick the TCB out >of the hashes so any message sent will be treated OOTB. > > No, that would not be good... since then you would have two associations up with the same addresses.. presuming of course you are leaving the other tcb alone.. >I have many choices with COOKIE-ECHO. I have few with INIT. > > And one could do the same thing with the INIT-ACK... send an abort() when you recognize the condition without an error cause.. No information revealed and to the attacker it will look like several other cases... Maybe the real solution is to just remove the error-cause from the implementors guide.. and give no clues as to why the abort was kicked out... this way the state is cleaned up.. the peer, if legitimate, will kick out the next HB on the old assoc.. and presto.. no information given and standard consistent behavior given. No differnt than any of your choices on the cookie-echo resonding with an abort.. > > >>I see no difference in this.. since a valid COOKIE-ECHO always generates >>a COOKIE-ACK... so you have given the same information >> >> > >No, I send ABORT instead of COOKIE-ACK when the connection indications >is refused on listening streams in the STREAMS implemtnation. > >But as I said above, one could reply with COOKIE-ACK and abort any attempt >to communicate on the association. > > > >> >>And back on the subject of fire-walls.. you missed my point.. the "trusted >>interfaces" that are open to INIT's are the very ones the attacker is >>using.. >> >> > >Then they are not "trusted." > > How will a general purpose server, say giving out HTTP pages, then work... if every interface has to be trusted... think Big-I not sigtran... > > >>this is a server running on the Big-I serving up web pages.. all of its >>interfaces are trusted.. >> >> > >All of its interfaces would then be "untrusted". > > So your firewall rules would kick out all inits and you would get NO communication.. Does not work.. sorry.. > > >>I am NOT talking sigtran.. where you have interfaces that are private... >>your firewall solution does not work for the Big-I >> >> > >Did I say it did? > Your trusted explanation above alludes to it.. web servers MUST work in such a "untrusted" environment.. shutting out all communication might keep out the bad guys.. but you won't get your web pages out either :-0 R > >--brian > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Sat Mar 8 03:06:26 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11445 for ; Sat, 8 Mar 2003 03:06:23 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h287dm0E015527 for ; Fri, 7 Mar 2003 23:39:48 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h287dlul013872 for ; Fri, 7 Mar 2003 23:39:47 -0800 (PST) Received: from gw.openss7.com (IDENT:2vJjLTIX7VRM0zttPPAslb4Ovrn9nHF4@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h287deVi022334 for ; Fri, 7 Mar 2003 23:39:41 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:Msi8fobLTGL2BEMQnFb9KA9FgqQ8JYSM@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h287XYD04686; Sat, 8 Mar 2003 00:33:34 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h287XX725274; Sat, 8 Mar 2003 00:33:33 -0700 Date: Sat, 8 Mar 2003 00:33:33 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030308003333.A20117@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Fri, Mar 07, 2003 at 04:51:12PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan, On Fri, 07 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > I still don't follow you at all... What you can know is that the INIT > is sent to the same endpoint, not that it comes from the same > endpoint... > > You know it goes there, so what? You don't know where it comes from... > D might or might not be part of the same endpoint that also uses C > (you don't know unless you take a look to the address parameter)... > What if another completely different peer sends an INIT > E:1000->B:1000? will you populate the Tie Tags as well? Will you > "recognize" it as being part of the association you are about the > create? Consider that if a completely different peer sends E:1000->B:1000 and places C or D in the address list that you will offer the potential attacker the unprotected vtag of the existing TCB in the cookie. Also, the INIT from D:1000->B:1000 with (C) in its list is not necessarily the peer at C:1000. This is the very reason why I do not check the source address list, just the source address in the packet: because none of the addresses in the list are reliable. Any attacker can put any source address in the list. This is similar to the hijack situation that 2.6 attempted to solve. 2.6 only addresses the situation where the attacker tries to add its own address to an existing address list when an established association exists. However, the same principle applies to hijacking hosts sending INITs that foolishly follow 2.18. Following your HOST A/B and HOST C/D example, I will add a malicious Host E. The sequence is as follows (note that Host E TCB's are from HOST A/B's view as the attacker can mimic whatever they like): >Host A/B Host E > >TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >A,B:1000 \ A:1000->C:1000 E:1000->B:1000 / E,C:1000 >C:1000 \ (C in list) / B:1000 >VTloc:W \ / VTloc:X >VTpeer:0 \ / VTpeer:0 >C-WAIT \ / C-WAIT > \--------------------\ /--------------------/ > \/ > /\ > / \ Host C/D > (1) <-------------------------/ \-------------------------> > > \ INIT ACK VT:X IT:Y > \ B:1000->E:1000 > \ VTloc:Y VTpeer:X > \TTloc:W TTpeer:0 > \ > \ > \--------------------\ > \ > \ > \ > \-------------------------> Host E > COOKIE ECHO VT:Y / TCB > D:1000->B:1000 / C,D:1000 > VTloc:Y VTpeer:X / A,B:1000 > TTloc:W TTpeer:0/ VTloc:X > / VTpeer:Y > / C-ECHOED > /--------------------/ > / > / > / > (2) <-------------------------/ >TCB >A,B:1000 >E,C:1000 >VTloc:W >VTpeer:X >ESTABLISHED At (1) by checking the source address list, Host A/B gives up the VT of the TCB to the attacker. At (2), if attacking Host E can return a COOKIE-ECHO before valid Host C/D returns an INIT-ACK, E will be installed in the TCB and will have hijacked the association by spoofing C in the address list. Certainly after (1), the attacker has the VT of the existing TCB and can easily wreak havoc with that (ABORT, HEARTBEAT-ACK, SHUTDOWN, etc.). If the attacker can turn around the COOKIE-ECHO fast enough (because it is "closer" than C/D or just because C/D is already heavily loaded, perhaps with bogus INITs from Host E or another attacking host), then it can easily hijack the association. After hijacking the association, either Host A/B does not support ADD-IP on the association, in which case the hijacker could have up to 30 seconds before C gets a HEARTBEAT, or, if Host A/B supports ADD-IP and the first action from E is to delete IP C. Another technique would be to get a new cookie and keep restarting the association before C gets a HEARTBEAT. At any rate, Host E has from 60 seconds to forever to pretend to be Host A/B. 30 seconds is a long time. For some period, the ULP at Host A/B believes that it is communicating with Host C/D but is in fact communicating with Host E. This is very bad. So how does Host A/B distinguish between this: >Host A/B Host E > >TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >A,B:1000 \ A:1000->C:1000 E:1000->B:1000 / E,C:1000 >C:1000 \ (C in list) / B:1000 >VTloc:W \ / VTloc:X >VTpeer:0 \ / VTpeer:0 >C-WAIT \ / C-WAIT > \--------------------\ /--------------------/ > \/ > /\ > / \ Host C/D > (1) <-------------------------/ \-------------------------> And this: >Host A/B Host C/D > >TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 >C:1000 \ (C in list) / B:1000 >VTloc:W \ / VTloc:X >VTpeer:0 \ / VTpeer:0 >C-WAIT \ / C-WAIT > \--------------------\ /--------------------/ > \/ > /\ > / \ > (1) <-------------------------/ \-------------------------> Without prior knowledge of address D it cannot distinguish between the two. Note that although forming a proper association here requires static port assignment on both sides, that is not true for the attack. Knowing the well-known server port on one side an the normal client dynamic port assignment range on the other, it is quite easy to attack a large number of clients simultaneously. The IP address I would spoof in my source address list would be the IP address and port of your on-line banking server, and I would send INITs repeatedly to the low end of your dynamic port range, and wait for you to give me your cookie in the INIT-ACK with tie-tags populated. Then, presto!, for 30 seconds I'm your bank. The current STREAMS OpenSS7 implementation does not consider the source address list and only uses packet header information (direct opposite of 2.18) and will not surrender the VT of the current association to D or E, but will populate tie tags with zero as you originally showed, if the connect() at Host A/B was only provided with C. If the connect() at Host A/B was provided with (C,D), the valid association will form and the attacker E cannot form an association (the INIT-ACK to E will have zero tie-tags). Note that in your previous example, populating tie tags just because B is in the address list opens the same vulnerability. The OpenSS7 implementation sends an INIT-ACK with zero tie tags and the association still forms. Also, in the 2.6 scenario, the OpenSS7 implementation populates the tie tag with zero because the attacker's IP address does not match the TCB, and again the attacker is thwarted while in more circumstances than 2.6's prescription the legitimate restarting node can add IP addresses (as long as it is not the primary which is added, or the restarting node tries INITs to other addresses as well). Caitlin's examples involved the INIT-ACK, which can always be looked up on VT if the sender of the INIT constrains its VT assignment to be unique. I don't see that I'm doing the wrong thing here in refusing to form associations with INITs sent from an unknown source address claiming to have the correct source address list. Am I not justified in the conclusion here is that one should not consider the source address list when searching for a matching TCB for received INIT messages? Not considering them closes these two vulnerabilities and yet even your last example can form an association if the ULP provides the addresses of the peer (C/D) to the connect() or t_connect() or the simple arrangement is made to INIT to the primary. IMO the right thing to do is to close the vulnerability for all associations at very minor expense of this one unnecessary corner case. (I say unnecessary because it is simple to configure Host A/B to INIT to A->C and Host C/D to INIT to C->A, or provide C/D to connect().) Following 2.18 opens up the vulnerability above and the vulnerability yet to be properly addressed by 2.6. Not following 2.18 closes both vulnerabilities. As this is the last example to be addressed, could you tell me again why I should consider the source address list when searching for a matching TCB on INIT and INIT-ACK? --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-2.cisco.com Sat Mar 8 05:44:13 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10184 for ; Sat, 8 Mar 2003 05:44:11 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h28A2JEY015726 for ; Sat, 8 Mar 2003 02:02:19 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h28A2I2B029531 for ; Sat, 8 Mar 2003 02:02:18 -0800 (PST) Received: from gw.openss7.com (IDENT:nQQtys7+J7k+Ud9dFnNdqHDjrhXoMymZ@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h28A0NOV016053 for ; Sat, 8 Mar 2003 02:00:24 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:LDqyFNbeVIDnilqfiCrdf1oj9e1kWN2Z@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h289ssD06880; Sat, 8 Mar 2003 02:54:54 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h289sro26444; Sat, 8 Mar 2003 02:54:53 -0700 Date: Sat, 8 Mar 2003 02:54:53 -0700 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030308025453.A26345@openss7.org> Reply-To: bidulock@openss7.org References: <20030303103316.B15597@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Mon, Mar 03, 2003 at 12:07:45PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Caitlin, Consider the following vulnerability in your example: Host A is establishing an association with Host B/C and malicious Host X at about the same time. INIT from A:1000 to B:1000 --------------------------------> INIT from A:1000 to X:1000 --------------------------------> <-----------------------------------------INIT-ACK to A:1000 from X:1000 (B) <-----------------------------------------INIT-ACK to A:1000 from B:1000 (C) Malicious Host X responds with INIT-ACK first with B's address in the source address list. When the second INIT-ACK arrives the first INIT is denied. Now, consider that malicious Host X places a large number of known addresses in its address list. The single INIT-ACK returned from X:1000 to A:1000 will deny service to every outstanding INIT from A:1000 to any of the addresses listed for the period of time that the association to X lives. Malicious Host X doesn't even have to send COOKIE-ACK, leaving Host A to retry COOKIE-ECHO and deny service until it times out. If Host A retries the INIT, the INIT-ACK will deny service for another timeout interval. Is that really what you want to do? How can you place any trust the source address list in the INIT or INIT-ACK? --brian On Mon, 03 Mar 2003, Caitlin Bestler wrote: > On 3/3/03, Brian F. G. Bidulock wrote: > > >Caitlin, > > > >What excess traffic? None of the actions in RFC 2960 > >section 5.2.4 can be detected until COOKIE-ECHO is > >received. Attempting to determine these things from the > >INIT or INIT-ACK is attempting to fortell the future. The > >result of trying to fortell the future is valid init > >attempts being refused. > > > >--brian > > > > > >On Mon, 03 Mar 2003, Caitlin Bestler wrote: > > > >> Brian, > >> > >> Is your point that there is no need to check the > >> INIT-ACK when it arrives because the other end can check > >> the INIT-ACK inside the State Cookie in the COOKIE-ECHO? > >> > >> If so, what is the benefit of deferring the check? The > >> extra costs, delay and a redundant COOKIE-ECHO, are > >> admittedly minor. But why tolerate any excess network > >> traffic that could have been prevented by simply using > >> the data already available? > >> > >> > >> Caitlin Bestler > >> http://asomi.com/CaitlinBestler/ > > > > INIT from A:1000 to B:1000 ------------------------------> > INIT form A:1000 to C:1000 ------------------------------> > <-------------------------------------INIT-ACK TO A:1000 > from [b,c]:1000 > <-------------------------------------INIT-ACK TO A:1000 > from [b,c]:1000 > > If A properly expands the scope of the first association's > TCB upon receipt to cover both b and c, then the second > INIT-ACK will be recognized as redundant. Only a single > COOKIE-ECHO will be sent. > > If A shirks the responsibility of examining the address > list within the INIT-ACK, and instead relies upon B/C to > do the check when it/they process their COOKIE-ECHOEs > then there will be *two* COOKIE-ECHOs sent. The second > COOKIE-ECHO is an excess message that should be prevented. > > Further, A SHOULD also realize that the TCB it created for > "A:1000 - C:1000" has been eclipsed by "A:1000 - [B,C]:1000" > That the "A:1000 - C:1000" TCB should be removed. More > importantly it should be prevent from retransmitting its > INIT message. If no action is taken that would be the > logical result as that it never received an INIT-ACK > response. > > There is no fortune-telling going on here. The INIT-ACK > clearly informs A that [B,C]:1000 is a single endpoint. > At the time that B/C generates each INIT-ACK it does not > have enough information to know that A is incorrectly > attempting to create two associations with identical > endpoints. After all, *no* records of prior INIT-ACKs > are supposed to be kept on the passive side. Doing so > creates a weakness for a denial-of-service attack. A (the > active side) has the first opportunity to identify and > correct the problem. > > If A wants to leave excess TCBs and indexes dangling around > that its business, but generating excess traffic (when there > was sufficient information to prevent those messages) is a > legitimate network issue. > > > > > > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-5.cisco.com Sat Mar 8 07:41:48 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02183 for ; Sat, 8 Mar 2003 07:41:47 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h28CD2hs023296; Sat, 8 Mar 2003 04:13:03 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEG59642; Sat, 8 Mar 2003 04:13:01 -0800 (PST) Message-ID: <3E69DE4D.8010609@cisco.com> Date: Sat, 08 Mar 2003 06:13:01 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Caitlin Bestler , sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030303103316.B15597@openss7.org> <20030308025453.A26345@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian: One key thing I don't think I understand in your scenario below... something Steve Bellovin once commented upon to me.. Why are you establishing an association to a malicious host? Its one thing when you are a passiver server... but it is quite another when YOU choose to make this establishement to a malicious host... I would classify this as way beyond a corner case ... Its quite likely to have a collision case.. where both attempt to contact at the same time.. but you making the connections by your choice to a good host and a malicious host seem a bit over the top... If you want to look at this case.. what about ----------INIT from A:1000 to X:1000--------------------> <---------INIT-ACK from X:1000 to A:1000 (IP-X,IP-B)--- I can't see how you would be concerned about the case below and not care about the same scenario with just a bit of different message ordering... So I don't see the merit in your argument and I think Caitlin's comments on extra network traffic are still not addressed by your comments below... especially since you are arguing from an extreme corner case... R Brian F. G. Bidulock wrote: >Caitlin, > >Consider the following vulnerability in your example: > >Host A is establishing an association with Host B/C and >malicious Host X at about the same time. > >INIT from A:1000 to B:1000 --------------------------------> >INIT from A:1000 to X:1000 --------------------------------> ><-----------------------------------------INIT-ACK to A:1000 > from X:1000 (B) ><-----------------------------------------INIT-ACK to A:1000 > from B:1000 (C) > >Malicious Host X responds with INIT-ACK first with B's address >in the source address list. > >When the second INIT-ACK arrives the first INIT is denied. > >Now, consider that malicious Host X places a large number of known >addresses in its address list. The single INIT-ACK returned >from X:1000 to A:1000 will deny service to every outstanding >INIT from A:1000 to any of the addresses listed for the period >of time that the association to X lives. > >Malicious Host X doesn't even have to send COOKIE-ACK, leaving >Host A to retry COOKIE-ECHO and deny service until it times out. >If Host A retries the INIT, the INIT-ACK will deny service for >another timeout interval. > >Is that really what you want to do? > >How can you place any trust the source address list in the INIT >or INIT-ACK? > >--brian > > >On Mon, 03 Mar 2003, Caitlin Bestler wrote: > > > >>On 3/3/03, Brian F. G. Bidulock wrote: >> >> >> >>>Caitlin, >>> >>>What excess traffic? None of the actions in RFC 2960 >>>section 5.2.4 can be detected until COOKIE-ECHO is >>>received. Attempting to determine these things from the >>>INIT or INIT-ACK is attempting to fortell the future. The >>>result of trying to fortell the future is valid init >>>attempts being refused. >>> >>>--brian >>> >>> >>>On Mon, 03 Mar 2003, Caitlin Bestler wrote: >>> >>> >>> >>>>Brian, >>>> >>>>Is your point that there is no need to check the >>>>INIT-ACK when it arrives because the other end can check >>>>the INIT-ACK inside the State Cookie in the COOKIE-ECHO? >>>> >>>>If so, what is the benefit of deferring the check? The >>>>extra costs, delay and a redundant COOKIE-ECHO, are >>>>admittedly minor. But why tolerate any excess network >>>>traffic that could have been prevented by simply using >>>>the data already available? >>>> >>>> >>>>Caitlin Bestler >>>>http://asomi.com/CaitlinBestler/ >>>> >>>> >>INIT from A:1000 to B:1000 ------------------------------> >>INIT form A:1000 to C:1000 ------------------------------> >><-------------------------------------INIT-ACK TO A:1000 >> from [b,c]:1000 >><-------------------------------------INIT-ACK TO A:1000 >> from [b,c]:1000 >> >>If A properly expands the scope of the first association's >>TCB upon receipt to cover both b and c, then the second >>INIT-ACK will be recognized as redundant. Only a single >>COOKIE-ECHO will be sent. >> >>If A shirks the responsibility of examining the address >>list within the INIT-ACK, and instead relies upon B/C to >>do the check when it/they process their COOKIE-ECHOEs >>then there will be *two* COOKIE-ECHOs sent. The second >>COOKIE-ECHO is an excess message that should be prevented. >> >>Further, A SHOULD also realize that the TCB it created for >>"A:1000 - C:1000" has been eclipsed by "A:1000 - [B,C]:1000" >>That the "A:1000 - C:1000" TCB should be removed. More >>importantly it should be prevent from retransmitting its >>INIT message. If no action is taken that would be the >>logical result as that it never received an INIT-ACK >>response. >> >>There is no fortune-telling going on here. The INIT-ACK >>clearly informs A that [B,C]:1000 is a single endpoint. >>At the time that B/C generates each INIT-ACK it does not >>have enough information to know that A is incorrectly >>attempting to create two associations with identical >>endpoints. After all, *no* records of prior INIT-ACKs >>are supposed to be kept on the passive side. Doing so >>creates a weakness for a denial-of-service attack. A (the >>active side) has the first opportunity to identify and >>correct the problem. >> >>If A wants to leave excess TCBs and indexes dangling around >>that its business, but generating excess traffic (when there >>was sufficient information to prevent those messages) is a >>legitimate network issue. >> >> >> >> >> >> >>Caitlin Bestler >>http://asomi.com/CaitlinBestler/ >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Sat Mar 8 09:54:54 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27761 for ; Sat, 8 Mar 2003 09:54:50 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h28Eoo0E007088 for ; Sat, 8 Mar 2003 06:50:51 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h28EooYs029757 for ; Sat, 8 Mar 2003 06:50:50 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h28EogoU008517 for ; Sat, 8 Mar 2003 06:50:43 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h28ERsF17629 for ; Sat, 8 Mar 2003 16:27:54 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 8 Mar 2003 16:24:31 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 8 Mar 2003 16:24:31 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 8 Mar 2003 16:24:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Sat, 8 Mar 2003 16:24:29 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLlRebW1nILzqhYRqWCqeN1ShjYEgAMGOFg From: To: Cc: , , X-OriginalArrivalTime: 08 Mar 2003 14:24:30.0714 (UTC) FILETIME=[6EC995A0:01C2E57E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA27761 Hi Brian, > Ivan, > > On Fri, 07 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > > > I still don't follow you at all... What you can know is > that the INIT > > is sent to the same endpoint, not that it comes from the same > > endpoint... > > > > You know it goes there, so what? You don't know where > it comes from... > > D might or might not be part of the same endpoint that > also uses C > > (you don't know unless you take a look to the address > parameter)... > > What if another completely different peer sends an INIT > > E:1000->B:1000? will you populate the Tie Tags as well? Will you > > "recognize" it as being part of the association you are > about the > > create? > > Consider that if a completely different peer sends E:1000->B:1000 and > places C or D in the address list that you will offer the potential > attacker the unprotected vtag of the existing TCB in the cookie. I don't think so... We realized about this quite many bake offs ago, and that's the reason why section 2.6 is there. Since you recognize that the peer apparently tries to add a new address, you don't send back the INIT ACK. I personally think that it is better to send the INIT ACK to any of the "old addresses" (C or D in this case) instead of sending the ABORT. But in any case, the INIT ACK will not be sent to E. Brian, the other mail conversation with topic "Address List Change on Restart" is just about this case... :-/ > Also, the INIT from D:1000->B:1000 with (C) in its list is not > necessarily the peer at C:1000. You mean that the INIT received from D could have been sent by an attacker that for some reason new that Host A/B was establishing an association with C? Interesting, however, we though about exactly this scenario when writing section 2.6, and if you read the new text for section 5.2.1 of RFC 2960, while in the COOKIE WAIT state, you would send the INIT ACK back to C, not to D. I personally think that this same approach could be taken to address the case where the INIT receiver is in the ESTABLISHED state, i.e., sending back the INIT ACK to an "old address" instead of the ABORT... This is precisely to avoid giving the VT (since you use the same one) to an attacker... > This is the very reason why I do not check the source address > list, just > the source address in the packet: because none of the addresses in the > list are reliable. Any attacker can put any source address > in the list. But those cases are already covered by section 2.6. > This is similar to the hijack situation that 2.6 attempted to solve. It is not similar, it is exactly that situation... > 2.6 only addresses the situation where the attacker tries to > add its own > address to an existing address list when an established association > exists. However, the same principle applies to hijacking > hosts sending > INITs that foolishly follow 2.18. Following your HOST A/B > and HOST C/D > example, I will add a malicious Host E. > > The sequence is as follows (note that Host E TCB's are from HOST A/B's > view as the attacker can mimic whatever they like): > >Host A/B Host E > >TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >A,B:1000 \ A:1000->C:1000 E:1000->B:1000 / E,C:1000 >C:1000 \ (C in list) / B:1000 >VTloc:W \ / VTloc:X >VTpeer:0 \ / VTpeer:0 >C-WAIT \ / C-WAIT > \--------------------\ /--------------------/ > \/ > /\ > / \ Host C/D > (1) <-------------------------/ \-------------------------> > > \ INIT ACK VT:X IT:Y > \ B:1000->E:1000 > \ VTloc:Y VTpeer:X > \TTloc:W TTpeer:0 This is the step where you are wrong... Go read section 2.6 (new text for section 5.2.1 of RFC 2960, at the end of the first paragraph) and you will see that this INIT ACK would go to C, not to E... We realized about this, and that's why we changed it... But in any case this discussion is interesting, we might even find some new problem we have to fix... > \ > \ > \--------------------\ > \ > \ > \ > \-------------------------> Host E > COOKIE ECHO VT:Y / TCB > D:1000->B:1000 / C,D:1000 > VTloc:Y VTpeer:X / A,B:1000 > TTloc:W TTpeer:0/ VTloc:X > / VTpeer:Y > / C-ECHOED > /--------------------/ > / > / > / > (2) <-------------------------/ >TCB >A,B:1000 >E,C:1000 >VTloc:W >VTpeer:X >ESTABLISHED > > At (1) by checking the source address list, Host A/B gives up > the VT of > the TCB to the attacker. Read above. > At (2), if attacking Host E can return a COOKIE-ECHO before valid Host > C/D returns an INIT-ACK, E will be installed in the TCB and will have > hijacked the association by spoofing C in the address list. We will never reach this point, see above. > Certainly after (1), the attacker has the VT of the existing > TCB and can > easily wreak havoc with that (ABORT, HEARTBEAT-ACK, SHUTDOWN, etc.). That was a problem with current RFC 2960 and that's why it was changed by the IG, see above... > If the attacker can turn around the COOKIE-ECHO fast enough > (because it > is "closer" than C/D or just because C/D is already heavily loaded, > perhaps with bogus INITs from Host E or another attacking > host), then it > can easily hijack the association. Nope... > After hijacking the association, either Host A/B does not > support ADD-IP > on the association, in which case the hijacker could have up to 30 > seconds before C gets a HEARTBEAT, or, if Host A/B supports ADD-IP and > the first action from E is to delete IP C. Another technique would be > to get a new cookie and keep restarting the association > before C gets a > HEARTBEAT. At any rate, Host E has from 60 seconds to forever to > pretend to be Host A/B. 30 seconds is a long time. It is funny to read that you are basically explaining the situation in the same way we did when we decided to change section 5.2.1... :-) > For some period, the ULP at Host A/B believes that it is communicating > with Host C/D but is in fact communicating with Host E. This is very > bad. But this won't happen, as explained above... > So how does Host A/B distinguish between this: > >Host A/B Host E > >TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >A,B:1000 \ A:1000->C:1000 E:1000->B:1000 / E,C:1000 >C:1000 \ (C in list) / B:1000 >VTloc:W \ / VTloc:X >VTpeer:0 \ / VTpeer:0 >C-WAIT \ / C-WAIT > \--------------------\ /--------------------/ > \/ > /\ > / \ Host C/D > (1) <-------------------------/ \-------------------------> > > And this: > >Host A/B Host C/D > >TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 >C:1000 \ (C in list) / B:1000 >VTloc:W \ / VTloc:X >VTpeer:0 \ / VTpeer:0 >C-WAIT \ / C-WAIT > \--------------------\ /--------------------/ > \/ > /\ > / \ > (1) <-------------------------/ \-------------------------> > > Without prior knowledge of address D it cannot distinguish between the > two. In any case the INIT ACK from Host A/B will go to C. So, if we have an attacker here, the INIT ACK will be lost... It is not possible that Host E makes Host A/B think that he is Host C/D (at least, not in the way you are trying)... > Note that although forming a proper association here requires static > port assignment on both sides, that is not true for the > attack. Knowing > the well-known server port on one side an the normal client > dynamic port > assignment range on the other, it is quite easy to attack a > large number > of clients simultaneously. The IP address I would spoof in my source > address list would be the IP address and port of your on-line banking > server, and I would send INITs repeatedly to the low end of > your dynamic > port range, and wait for you to give me your cookie in the > INIT-ACK with > tie-tags populated. Then, presto!, for 30 seconds I'm your bank. I was also quite happy when we fixed this... The idea above looks like genial, doesn't it? But due to the changes included in section 2.6 of the IG, this is not possible anymore :-) > The current STREAMS OpenSS7 implementation does not consider > the source > address list and only uses packet header information (direct > opposite of > 2.18) and will not surrender the VT of the current association to D or > E, but will populate tie tags with zero as you originally > showed, if the > connect() at Host A/B was only provided with C. But then, could you explain me how would you solve the "original" INIT collision between Host A/B and Host C/D? You argued that you would be able to recognize the peer, but I'm still wondering why, and you didn't answer... I copy here again the diagram: Host A/B Host C/D TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 C:1000 \ / B:1000 VTloc:W \ / VTloc:X VTpeer:0 \ / VTpeer:0 C-WAIT \ / C-WAIT \--------------------\ /--------------------/ \/ /\ / \ <-------------------------/ \-------------------------> \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:Z / \ B:1000->D:1000 C:1000->A:1000 / \ VTloc:Y VTpeer:X VTloc:Z VTpeer:W / \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ \ / \ / \--------------------\ /--------------------/ \/ /\ / \ <-------------------------/ \-------------------------> TCB \ COOKIE ECHO VT:Z COOKIE ECHO VT:Y / TCB A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 C,D:1000 \ VTloc:Z VTpeer:W VTloc:Y VTpeer:X / A,B:1000 VTloc:W \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ VTloc:X VTpeer:Z \ / VTpeer:Y C-ECHOED \ / C-ECHOED \--------------------\ /--------------------/ \/ /\ / \ X<-------------------------/ \------------------------->X I don't think you are able to manage this case, Brian... So far I didn't follow any of your explanations... :-/ > If the connect() at Host A/B was provided with (C,D), the valid > association will form and the attacker E cannot form an > association (the > INIT-ACK to E will have zero tie-tags). But you cannot know beforehand all the addresses of all the possible hosts (basically all of them if you have, let's say, an HTTP server)... This is a special feature, a special situation, you are able to do so only if you are in a "restricted world" in which you already know everybody... but this is not the common case... > Note that in your previous example, populating tie tags just because B > is in the address list opens the same vulnerability. The OpenSS7 > implementation sends an INIT-ACK with zero tie tags and the > association > still forms. I think that at this point it is quite clear that it is not an issue since the INIT ACK is sent back to the "old address" > Also, in the 2.6 scenario, the OpenSS7 implementation > populates the tie > tag with zero because the attacker's IP address does not > match the TCB, > and again the attacker is thwarted while in more circumstances than > 2.6's prescription the legitimate restarting node can add IP addresses > (as long as it is not the primary which is added, or the > restarting node > tries INITs to other addresses as well). Following 2.6 you can address all those cases, and you are still protected against attackers... However, I would like to know what the other authors think about modifying 2.6 to manage the other case (association not in the COOKIE WAIT state) in the same way (i.e., not sending the ABORT but sending the INIT ACK to any of the "old addresses"). From my point of view this solution is neater and would make life easier to a true restarted peer that adds addresses... Randall, the others, what do you think? > Caitlin's examples involved the INIT-ACK, which can always be > looked up > on VT if the sender of the INIT constrains its VT assignment to be > unique. > > I don't see that I'm doing the wrong thing here in refusing to form > associations with INITs sent from an unknown source address > claiming to > have the correct source address list. If you do so, it might be that a peer that has restarted and added an address (which is the source of the INIT) is unable to re-establish the association... > Am I not justified in the conclusion here is that one should not > consider the source address list when searching for a matching TCB for > received INIT messages? Not considering them closes these two > vulnerabilities and yet even your last example can form an association Well, as you see, they are not vulnerabilities... they are already covered by section 2.6... > if the ULP provides the addresses of the peer (C/D) to the > connect() or But you cannot do that... Brian, come on... How are you going to do that if you are an HTTP server using SCTP and running on the Internet? It is impossible... Brian, in your "environment" you can do so, because it is very restricted. However, when you speak about the whole world, you simply cannot. > t_connect() or the simple arrangement is made to INIT to the primary. You don't know which is the address that a host (to which you are sending an INIT) is going to use as a primary an which it is not, simply because you only know one of those. No, Brian, this is not a valid solution... > IMO the right thing to do is to close the vulnerability for all > associations at very minor expense of this one unnecessary > corner case. Well, the corner case is managed in the right way, and so you do with the "vulnerabilities", which are not such... > (I say unnecessary because it is simple to configure Host A/B > to INIT to > A->C and Host C/D to INIT to C->A, or provide C/D to connect().) Simple? How is it going to be simple? How are you going to know in advance all the hosts that could eventually establish an association with you when we are speaking about billions of them? > Following 2.18 opens up the vulnerability above and the vulnerability > yet to be properly addressed by 2.6. Not following 2.18 closes both > vulnerabilities. Actually I think that it is basically the opposite. Following those sections makes you perfectly manage those "special" situations... and closes the vulnerabilities that comes due the fact that you use VT (plus destination address and source/destination ports) as the way to identify an association. As Randall has already stated, this could make an attack eventually easier to perform... > As this is the last example to be addressed, could you tell > me again why > I should consider the source address list when searching for > a matching > TCB on INIT and INIT-ACK? I have already told you. You should do that mainly because: a) That way you cover the problems with peers that restarted and added addresses. b) You also manage in the right way the INIT collisions. c) You don't compromise the security, losing part of the protection to attacks that the conjunction of source/destination address/port + VT gives you. We have never said that the VT is not a good choice to use to find an established association. Especially when transferring data, the randomness of the VT makes it very likely to use it as a hash key. However, once you find the association, you should also verify that both the source and destination address/port are right. And the opposite, if you don't find the association and the datagram contained an INIT/INIT ACK, you should look for the association using the address parameters... And now that I have answered, could you tell me how do you do it to manage the INIT collision case? (Though, your sentence "at very minor expense of this one unnecessary corner case" makes me think that there is not such solution). BR Iván Arias Rodríguez > --brian > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > From owner-extdom.sctp-impl@sj-core-5.cisco.com Sat Mar 8 10:45:33 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08127 for ; Sat, 8 Mar 2003 10:45:30 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h28FW1hs010003; Sat, 8 Mar 2003 07:32:02 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEG64515; Sat, 8 Mar 2003 07:32:00 -0800 (PST) Message-ID: <3E6A0CF0.2010803@cisco.com> Date: Sat, 08 Mar 2003 09:32:00 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030308003333.A20117@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Ivan, > >On Fri, 07 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > >> I still don't follow you at all... What you can know is that the INIT >> is sent to the same endpoint, not that it comes from the same >> endpoint... >> >> You know it goes there, so what? You don't know where it comes from... >> D might or might not be part of the same endpoint that also uses C >> (you don't know unless you take a look to the address parameter)... >> What if another completely different peer sends an INIT >> E:1000->B:1000? will you populate the Tie Tags as well? Will you >> "recognize" it as being part of the association you are about the >> create? >> >> > >Consider that if a completely different peer sends E:1000->B:1000 and >places C or D in the address list that you will offer the potential >attacker the unprotected vtag of the existing TCB in the cookie. > > You are not addressing Ivan's point.. He was pointing out to you that you must be able to distinguish the collision case from the non-collision.. You also make the assumption that the attacker knows that you are attempting at that very moment to setup an association with C /D. This it does not know.. and would not even realize is the V-Tag for your forming association.. what the attacker would be more likely to be attempting is to camp on addresses (as I just noted to you in my other email)... >Also, the INIT from D:1000->B:1000 with (C) in its list is not >necessarily the peer at C:1000. > >This is the very reason why I do not check the source address list, just >the source address in the packet: because none of the addresses in the >list are reliable. Any attacker can put any source address in the list. > > But in the end you must go through this same list in the COOKIE-ECHO.. and here if some attacker is placing some other peers addresses in the list you end up at the same point.. an association that is camping on another's addresses... same result... >This is similar to the hijack situation that 2.6 attempted to solve. >2.6 only addresses the situation where the attacker tries to add its own >address to an existing address list when an established association >exists. However, the same principle applies to hijacking hosts sending >INITs that foolishly follow 2.18. Following your HOST A/B and HOST C/D >example, I will add a malicious Host E. > I think the right fix for 2.6 is to remove the error cause.. and now you just get an abort.. this does not share information and you can get such an abort for a non-listening port... As to your statement above.. it is far far easier for the attacker to just camp on addresses.. in fact in the collision scenario you paint assuming that the hijacker magically knows you have sent an INIT out and in the small 1-50ms window can get an INIT back that happens to have the very addresses you put in the outing INIT's .. very very far-fetched .. But lets consider your sequence below... >The sequence is as follows (note that Host E TCB's are from HOST A/B's >view as the attacker can mimic whatever they like): > > > >>Host A/B Host E >> >>TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >>A,B:1000 \ A:1000->C:1000 E:1000->B:1000 / E,C:1000 >>C:1000 \ (C in list) / B:1000 >>VTloc:W \ / VTloc:X >>VTpeer:0 \ / VTpeer:0 >>C-WAIT \ / C-WAIT >> \--------------------\ /--------------------/ >> \/ >> /\ >> / \ Host C/D >> (1) <-------------------------/ \-------------------------> >> >> \ INIT ACK VT:X IT:Y >> \ B:1000->E:1000 >> \ VTloc:Y VTpeer:X >> \TTloc:W TTpeer:0 >> \ >> \ >> \--------------------\ >> \ >> \ >> \ >> \-------------------------> Host E >> COOKIE ECHO VT:Y / TCB >> D:1000->B:1000 / C,D:1000 >> VTloc:Y VTpeer:X / A,B:1000 >> TTloc:W TTpeer:0/ VTloc:X >> / VTpeer:Y >> / C-ECHOED >> /--------------------/ >> / >> / >> / >> (2) <-------------------------/ >> >> And now what is different in this case with the scenario that is painted if you subtract out your sending the INIT? Nothing.. you think you have an association to C/D and X.. and you don't.. And more so, since the INIT-ACK/COOKIE-ECHO happens faster with the attacker.. even your solution brings up the association with the attacker.. until the first HB to C/D goes out.. In fact this is just one possibility you also have: Host A/B Host E TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB A,B:1000 \ A:1000->C:1000 E:1000->B:1000 / E,C:1000 C:1000 \ (C in list) / B:1000 VTloc:W \ / VTloc:X VTpeer:0 \ / VTpeer:0 C-WAIT \ / C-WAIT \--------------------\ /--------------------/ \/ /\ / \ Host C/D <-------------------------/ \-------------------------> / \ INIT ACK VT:X IT:Y / \ B:1000->E:1000 / \ VTloc:Y VTpeer:X INIT-ACK / \TTloc:W TTpeer:0 VT:W IT:Q / \ / \ / \--------------------\ / (1) <-------------------------------------------/ \ \ \-------------------------> Host E COOKIE ECHO VT:Y / TCB D:1000->B:1000 / C,D:1000 VTloc:Y VTpeer:X / A,B:1000 TTloc:W TTpeer:0/ VTloc:X / VTpeer:Y / C-ECHOED /--------------------/ / / / X <-------------------------/ A far more likely scenario, since the attacker must make 1.5 RTT to the 1 RTT (minus the time between sending the INIT and the evil attackers INIT arrives). In the above scenario, by checking the address list, finding the TCB has been updated a second time, but now with less addresses, the sender of the INIT can then pick a new IT, reseting it because it realizes something is up i.e. the address list changed between one INIT-ACK and the INIT that came in.. and then send a NEW INIT with this new tag, get a second response from the real peer and of course the Cookie-Echo from the attacker will be thrown away.. Now of course if you don't check the addresses, you blindly start a new association and so when the evil attackers COOKIE-ECHO arrives after sending the second cookie (not shown) you accept the association with the evil attacker.. where if you had checked the address list you would not have.. instead you would send a new INIT with new vtag... I think the above scenario I have illustrated is far more likely (due to RTT times)... but in your illustrated scenario.. it matters not if you check the address list or not.. if the attacker can get a INIT/COOKIE-ECHO to you before the INIT-ACK from the real peer comes back you will establish an association with the bad guy.... > > >>TCB >>A,B:1000 >>E,C:1000 >>VTloc:W >>VTpeer:X >>ESTABLISHED >> >> > >At (1) by checking the source address list, Host A/B gives up the VT of >the TCB to the attacker. > No by checking the address list the peer can make the connection that I have shown above and send a new INIT to the valid peer so the attacker is foiled.. in your illustrated scenario it makes no difference if you check the address list or not.. you still bring up the association... >At (2), if attacking Host E can return a COOKIE-ECHO before valid Host >C/D returns an INIT-ACK, E will be installed in the TCB and will have >hijacked the association by spoofing C in the address list. > > As I said above.. it does not really matter, if the COOKIE-ECHO beats your peers INIT-ACK back then your implementation would bring up the evil association the same as if you checked the address list.. Only thing checking the address list can do is help you in the far more likely scenario that I have painted above... >Certainly after (1), the attacker has the VT of the existing TCB and can >easily wreak havoc with that (ABORT, HEARTBEAT-ACK, SHUTDOWN, etc.). > > What existing TCB.. this is a forming association.. if it was a existing TCB it would get an ABORT() (aka 2.6 of the IG which as I said will loose the error cause)... If you have not yet formed an association your not checking the INIT/INIT-ACK is not going to change the outcome of the above scenario.. you end up in the same place... an association to E that includes addresses to C/D.. >If the attacker can turn around the COOKIE-ECHO fast enough (because it >is "closer" than C/D or just because C/D is already heavily loaded, >perhaps with bogus INITs from Host E or another attacking host), then it >can easily hijack the association. > Look at your scenario.. if the attacker, with this ability to hit this limited window, is that close.. it will not matter if you check the addresses up front or not.. before the real INIT-ACK comes back you have formed an association with E.. in your case or in what everyone else does... this is not a hijack by the way.. a hijack is when you have an existing association.. there is none here.. if there were a ABORT would have been sent... > >After hijacking the association, either Host A/B does not support ADD-IP >on the association, in which case the hijacker could have up to 30 >seconds before C gets a HEARTBEAT, or, if Host A/B supports ADD-IP and >the first action from E is to delete IP C. Another technique would be >to get a new cookie and keep restarting the association before C gets a >HEARTBEAT. At any rate, Host E has from 60 seconds to forever to >pretend to be Host A/B. 30 seconds is a long time. > > And how is the scenario different with your implementation.. its not.. if the attacker can get the message exchange done ahead of the real peer.. you end up in the same place.. And has to the Add-IP there will be some changes coming that Michael and I are working on.. probably a seperate draft.. but something that can be done... >For some period, the ULP at Host A/B believes that it is communicating >with Host C/D but is in fact communicating with Host E. This is very >bad. > >So how does Host A/B distinguish between this: > > > >>Host A/B Host E >> >>TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >>A,B:1000 \ A:1000->C:1000 E:1000->B:1000 / E,C:1000 >>C:1000 \ (C in list) / B:1000 >>VTloc:W \ / VTloc:X >>VTpeer:0 \ / VTpeer:0 >>C-WAIT \ / C-WAIT >> \--------------------\ /--------------------/ >> \/ >> /\ >> / \ Host C/D >> (1) <-------------------------/ \-------------------------> >> >> > >And this: > > > >>Host A/B Host C/D >> >>TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >>A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 >>C:1000 \ (C in list) / B:1000 >>VTloc:W \ / VTloc:X >>VTpeer:0 \ / VTpeer:0 >>C-WAIT \ / C-WAIT >> \--------------------\ /--------------------/ >> \/ >> /\ >> / \ >> (1) <-------------------------/ \-------------------------> >> >> > >Without prior knowledge of address D it cannot distinguish between the >two. > >Note that although forming a proper association here requires static >port assignment on both sides, that is not true for the attack. Knowing > No, static port assignments are NOT required.. there are other methods that dynamic ports can be used.. RSERPOOL is an example of this... >the well-known server port on one side an the normal client dynamic port >assignment range on the other, it is quite easy to attack a large number >of clients simultaneously. The IP address I would spoof in my source >address list would be the IP address and port of your on-line banking >server, and I would send INITs repeatedly to the low end of your dynamic >port range, and wait for you to give me your cookie in the INIT-ACK with >tie-tags populated. Then, presto!, for 30 seconds I'm your bank. > > If I am talking to my bank I don't think I would be using clear-text type conversations and I fail to see how you have illustrated anything that won't fall onto your implementation as well.. I , the attacker turn the COOKIE-ECHO around as you have painted fast enough.. guess what.. you think I am your bank as well.. sorry your method of waiting until you see the COOKIE-ECHO is not going to help you at all.. >The current STREAMS OpenSS7 implementation does not consider the source >address list and only uses packet header information (direct opposite of >2.18) and will not surrender the VT of the current association to D or >E, but will populate tie tags with zero as you originally showed, if the >connect() at Host A/B was only provided with C. > > And as you illustrate when E turns the INIT-ACK and COOKIE-ACK around faster than C, your implementation will have you speaking to the attacker as well.. And whats this about a current assocation? There IS NOT a current assocaition... If there was you give E an ABORT if of course you check the address list.. >If the connect() at Host A/B was provided with (C,D), the valid >association will form and the attacker E cannot form an association (the >INIT-ACK to E will have zero tie-tags). > > Ahh, your argument then is for full pre-knowledge of all addresses... This is a different argument and as I said it is non-general purpose... >Note that in your previous example, populating tie tags just because B >is in the address list opens the same vulnerability. The OpenSS7 >implementation sends an INIT-ACK with zero tie tags and the association >still forms. > The point is you will NOT form an association to valid users.. this is what we have demonstrated to you ... The weaknesses you lay out are there in your implementation when a full peer address list is not present... I see no difference > >Also, in the 2.6 scenario, the OpenSS7 implementation populates the tie >tag with zero because the attacker's IP address does not match the TCB, >and again the attacker is thwarted while in more circumstances than >2.6's prescription the legitimate restarting node can add IP addresses >(as long as it is not the primary which is added, or the restarting node >tries INITs to other addresses as well). > > >Caitlin's examples involved the INIT-ACK, which can always be looked up >on VT if the sender of the INIT constrains its VT assignment to be >unique. > >I don't see that I'm doing the wrong thing here in refusing to form >associations with INITs sent from an unknown source address claiming to >have the correct source address list. > >Am I not justified in the conclusion here is that one should not >consider the source address list when searching for a matching TCB for >received INIT messages? Not considering them closes these two >vulnerabilities and yet even your last example can form an association >if the ULP provides the addresses of the peer (C/D) to the connect() or >t_connect() or the simple arrangement is made to INIT to the primary. >IMO the right thing to do is to close the vulnerability for all >associations at very minor expense of this one unnecessary corner case. >(I say unnecessary because it is simple to configure Host A/B to INIT to >A->C and Host C/D to INIT to C->A, or provide C/D to connect().) > >Following 2.18 opens up the vulnerability above and the vulnerability >yet to be properly addressed by 2.6. Not following 2.18 closes both >vulnerabilities. > The vulnerability you illustrate is in both cases.. and has nothing to do with checking addresses.. > >As this is the last example to be addressed, could you tell me again why >I should consider the source address list when searching for a matching >TCB on INIT and INIT-ACK? > > So, what can we learn from all of this discussion: 1) Checking the addresses does not change the outcome if the evil attacker can turn things around fast as in your illustration 2) Checking addresses WILL allow you to catch the more likely case that the valid peers INIT-ACK arrives after the hackers INIT.. 2a) One should check if the INIT-ACK comes back with different addresses and then restart the INIT process with a new Tag... 3) Not checking addresses will lead to bringing up the association with the hacker. 4) Not checking the addresses will reduce the protection in the V-Tag (as we discussed previously) 5) If one is worried about the "fast" hacker (your illustration above), then the only way to avoid it is to either: a) Have a pre-listing of all valid address for the peer. b) Require a HB to each of the peers listed addresses before allowing data to flow.. Note: I think either a or b is a bit restrictive, but thats ok if one is worried about this scenario one can put these requirements in. 6) NOT checking addresses will lead to a scenario (as illustrated by Ivan) where a valid association cannot be started. 7) NOT checking addresses will lead as Caitlin as shown to an excess message. You have pretty much convinced me we really need to require that addresses be confirmed... Vtag hash lookups are ok, but addresses will need to be validated as well since without it they weaken security in at least 2 different ways (the vtag is weaker and the more common scenario I illustrated can not be prevented). We may even want to add a note in the IG stating that a endpoint MAY wish to heartbeat every listed address if it feels it cannot trust the peer.. wordsmitthing required a lot of course... R >--brian > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-2.cisco.com Sat Mar 8 15:48:29 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05445 for ; Sat, 8 Mar 2003 15:48:28 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h28Kc8EY015129 for ; Sat, 8 Mar 2003 12:38:09 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h28Kc8Oh022264 for ; Sat, 8 Mar 2003 12:38:08 -0800 (PST) Received: from gw.openss7.com (IDENT:hJglDSqFiTYMK9qL2Smhwzm89wXwaj6I@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h28KaDln020640 for ; Sat, 8 Mar 2003 12:36:13 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:wgAuF+eRYKdfrfpXvLt6lJ1xa1FAY+UN@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h28KUjD18197; Sat, 8 Mar 2003 13:30:45 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h28KUiR01100; Sat, 8 Mar 2003 13:30:44 -0700 Date: Sat, 8 Mar 2003 13:30:44 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: sctp-impl@external.cisco.com, rrs@cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030308133044.A32275@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Sat, Mar 08, 2003 at 04:24:29PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan, On Sat, 08 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > Host A/B Host C/D > > TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB > A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 > C:1000 \ / B:1000 > VTloc:W \ / VTloc:X > VTpeer:0 \ / VTpeer:0 > C-WAIT \ / C-WAIT > \--------------------\ /--------------------/ > \/ > /\ > / \ > <-------------------------/ \-------------------------> Populating tie-tags with zero is correct? (IG 2.6) Sending the INIT-ACK to C or D is moot (because it is sent to D if the INIT arrived just before sending the INIT from A.) > > \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:Z / > \ B:1000->D:1000 C:1000->A:1000 / > \ VTloc:Y VTpeer:X VTloc:Z VTpeer:W / > \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ > \ / > \ / > \--------------------\ /--------------------/ > \/ > /\ > / \ > <-------------------------/ \-------------------------> The host just copies the INIT-ACK info and echoes the cookie. > > TCB \ COOKIE ECHO VT:Z COOKIE ECHO VT:Y / TCB > A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 > C,D:1000 \ VTloc:Z VTpeer:W VTloc:Y VTpeer:X / A,B:1000 > VTloc:W \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ VTloc:X > VTpeer:Z \ / VTpeer:Y > C-ECHOED \ / C-ECHOED > \--------------------\ /--------------------/ > \/ > /\ > / \ What have I done wrong to this point? (Note that I have not looked at the source address list in the INIT.) --brian > X<-------------------------/ \------------------------->X > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-2.cisco.com Sat Mar 8 20:10:01 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24281 for ; Sat, 8 Mar 2003 20:10:00 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2910BEY010923; Sat, 8 Mar 2003 17:00:11 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEG79841; Sat, 8 Mar 2003 17:00:09 -0800 (PST) Message-ID: <3E6A9219.50801@cisco.com> Date: Sat, 08 Mar 2003 19:00:09 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030308133044.A32275@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Ivan, > >On Sat, 08 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > >>Host A/B Host C/D >> >>TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >>A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 >>C:1000 \ / B:1000 >>VTloc:W \ / VTloc:X >>VTpeer:0 \ / VTpeer:0 >>C-WAIT \ / C-WAIT >> \--------------------\ /--------------------/ >> \/ >> /\ >> / \ >> <-------------------------/ \-------------------------> >> >> > >Populating tie-tags with zero is correct? (IG 2.6) > What tie-tags? so far I see a INIT being sent above.. > >Sending the INIT-ACK to C or D is moot (because it is sent to D >if the INIT arrived just before sending the INIT from A.) > > What does your statement have to do with anything.. you send a INIT to C (from A) and all of a sudden you get a INIT from D... you have NO idea that C and D are the same endpoint... so you MUST send back a INIT-ACK to D... > > >> \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:Z / >> \ B:1000->D:1000 C:1000->A:1000 / >> \ VTloc:Y VTpeer:X VTloc:Z VTpeer:W / >> \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ >> \ / >> \ / >> \--------------------\ /--------------------/ >> \/ >> /\ >> / \ >> <-------------------------/ \-------------------------> >> >> > >The host just copies the INIT-ACK info and echoes the cookie. > > > >>TCB \ COOKIE ECHO VT:Z COOKIE ECHO VT:Y / TCB >>A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 >>C,D:1000 \ VTloc:Z VTpeer:W VTloc:Y VTpeer:X / A,B:1000 >>VTloc:W \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ VTloc:X >>VTpeer:Z \ / VTpeer:Y >>C-ECHOED \ / C-ECHOED >> \--------------------\ /--------------------/ >> \/ >> /\ >> / \ >> >> > >What have I done wrong to this point? > He was illustrating what you are advocating, not looking in the INIT and INIT-ACK.. if you do look in the INIT, then at you will have populated the tie-tags since you would have recognized the associations as being related (you would have found C in the the INIT's list of addresses .. the one from D.. and then you would have found the TCB that sent the INIT to C...) > >(Note that I have not looked at the source address list in the INIT.) > > Yep and that is why your association will not come up when it should.. R >--brian > > > >> X<-------------------------/ \------------------------->X >> >> >> > > > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Sat Mar 8 22:31:33 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21040 for ; Sat, 8 Mar 2003 22:31:31 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h293LKhs017797 for ; Sat, 8 Mar 2003 19:21:20 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h293KXl7000262 for ; Sat, 8 Mar 2003 19:20:39 -0800 (PST) Received: from gw.openss7.com (IDENT:l9wHnyjfgn79zQGmB81en4gyJHoQGkTQ@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h293JJln028809 for ; Sat, 8 Mar 2003 19:19:19 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:zZs1KlwHZtQSGGL7LPY0Y5hVwrJsNB1F@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h293DnD24942; Sat, 8 Mar 2003 20:13:49 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h293DmA06261; Sat, 8 Mar 2003 20:13:48 -0700 Date: Sat, 8 Mar 2003 20:13:48 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030308201348.A5946@openss7.org> Reply-To: bidulock@openss7.org References: <20030308133044.A32275@openss7.org> <3E6A9219.50801@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E6A9219.50801@cisco.com>; from rrs@cisco.com on Sat, Mar 08, 2003 at 07:00:09PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Sat, 08 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >Ivan, > > > >On Sat, 08 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > > > >>Host A/B Host C/D > >> > >>TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB > >>A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 > >>C:1000 \ / B:1000 > >>VTloc:W \ / VTloc:X > >>VTpeer:0 \ / VTpeer:0 > >>C-WAIT \ / C-WAIT > >> \--------------------\ /--------------------/ > >> \/ > >> /\ > >> / \ > >> <-------------------------/ \-------------------------> > >> > >> > > > >Populating tie-tags with zero is correct? (IG 2.6) > > > What tie-tags? so far I see a INIT being sent above.. In the INIT-ACK being formulated at this point... > > > > > >Sending the INIT-ACK to C or D is moot (because it is sent to D > >if the INIT arrived just before sending the INIT from A.) > > > > > What does your statement have to do with anything.. you > send a INIT to C (from A) and all of a sudden you get a > INIT from D... you have NO idea that C and D are the same > endpoint... so you MUST send back a INIT-ACK to D... Huh? Is the new text in section 2.6 for section 5.2.1 in error? It tells me that in COOKIE-WAIT state I must send the INIT-ACK back to the same address that the original INIT (sent by this endpoint) was sent to. Yet you tell me I MUST send it to D? I'm glad you don't have a problem with me sending it to D (per RFC 2960) instead of to C (per IG 08 2.6). > > > > > > >> \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:Z / > >> \ B:1000->D:1000 C:1000->A:1000 / > >> \ VTloc:Y VTpeer:X VTloc:Z VTpeer:W / > >> \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ > >> \ / > >> \ / > >> \--------------------\ /--------------------/ > >> \/ > >> /\ > >> / \ > >> <-------------------------/ \-------------------------> > >> > >> > > > >The host just copies the INIT-ACK info and echoes the cookie. > > > > > > > >>TCB \ COOKIE ECHO VT:Z COOKIE ECHO VT:Y / TCB > >>A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 > >>C,D:1000 \ VTloc:Z VTpeer:W VTloc:Y VTpeer:X / A,B:1000 > >>VTloc:W \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ VTloc:X > >>VTpeer:Z \ / VTpeer:Y > >>C-ECHOED \ / C-ECHOED > >> \--------------------\ /--------------------/ > >> \/ > >> /\ > >> / \ > >> > >> > > > >What have I done wrong to this point? > > > > He was illustrating what you are advocating, not looking in the INIT > and INIT-ACK.. if you do look in the INIT, then at you will > have populated the tie-tags since you would have recognized the > associations as being related (you would have found C in the the > INIT's list of addresses .. the one from D.. and then you would > have found the TCB that sent the INIT to C...) But the tie-tags are not to be populated in COOKIE-WAIT states (according to RFC 2960 section 5.2.2) and in COOKIE-WAIT, COOKIE-ECHOED or SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New text for Section 5.2.2) Now you are telling me they should be populated? If they are populated and D is X (the attacker) then you will have surrendered the VT of the existing TCB to the attacker. So are you saying that I have done the wrong thing by putting zero in the tie-tags? Then is RFC 2960 section 5.2.2 and IG 08 section 2.6 new text for 5.2.2 in error? I would seriously like to know what I've done wrong up to this point. Your statements of what I have done wrong are not consistent with either the RFC or the IG.... Please take a closer look at it and tell me where I have gone astray. --brian > > > > >(Note that I have not looked at the source address list in the INIT.) > > > > > > Yep and that is why your association will not come up when it should.. But I have following the RFC and Section 2.6 to the letter (except for the C/D thing which doesn't change the result here.) --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-5.cisco.com Sun Mar 9 08:29:23 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12895 for ; Sun, 9 Mar 2003 08:29:21 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h29DGdhs026480; Sun, 9 Mar 2003 05:16:40 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEG96808; Sun, 9 Mar 2003 05:16:38 -0800 (PST) Message-ID: <3E6B3EB5.70405@cisco.com> Date: Sun, 09 Mar 2003 07:16:37 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030308133044.A32275@openss7.org> <3E6A9219.50801@cisco.com> <20030308201348.A5946@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Sat, 08 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian F. G. Bidulock wrote: >> >> >> >>>Ivan, >>> >>>On Sat, 08 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: >>> >>> >>> >>> >>>>Host A/B Host C/D >>>> >>>>TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >>>>A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 >>>>C:1000 \ / B:1000 >>>>VTloc:W \ / VTloc:X >>>>VTpeer:0 \ / VTpeer:0 >>>>C-WAIT \ / C-WAIT >>>> \--------------------\ /--------------------/ >>>> \/ >>>> /\ >>>> / \ >>>> <-------------------------/ \-------------------------> >>>> >>>> >>>> >>>> >>>Populating tie-tags with zero is correct? (IG 2.6) >>> >>> >>> >>What tie-tags? so far I see a INIT being sent above.. >> >> > >In the INIT-ACK being formulated at this point... > > > >> >> >> >> >>>Sending the INIT-ACK to C or D is moot (because it is sent to D >>>if the INIT arrived just before sending the INIT from A.) >>> >>> >>> >>> >>What does your statement have to do with anything.. you >>send a INIT to C (from A) and all of a sudden you get a >>INIT from D... you have NO idea that C and D are the same >>endpoint... so you MUST send back a INIT-ACK to D... >> >> > >Huh? Is the new text in section 2.6 for section 5.2.1 in error? >It tells me that in COOKIE-WAIT state I must send the INIT-ACK back >to the same address that the original INIT (sent by this endpoint) >was sent to. > >Yet you tell me I MUST send it to D? I'm glad you don't have a >problem with me sending it to D (per RFC 2960) instead of to C >(per IG 08 2.6). > > I had forgotten about that addition... and actually it is the right thing to do as well... This way if you did get a evil attacker sending in from 'E' as you painted in one of the other emails would not get the INIT-ACK back... and the peer at C/D would discard it... I will have to go check our implementation and see if we did this... if not we will get a patch out right away :> > > >>> >>> >>> >>> >>>> \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:Z / >>>> \ B:1000->D:1000 C:1000->A:1000 / >>>> \ VTloc:Y VTpeer:X VTloc:Z VTpeer:W / >>>> \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ >>>> \ / >>>> \ / >>>> \--------------------\ /--------------------/ >>>> \/ >>>> /\ >>>> / \ >>>> <-------------------------/ \-------------------------> >>>> >>>> >>>> >>>> >>>The host just copies the INIT-ACK info and echoes the cookie. >>> >>> >>> >>> >>> >>>>TCB \ COOKIE ECHO VT:Z COOKIE ECHO VT:Y / TCB >>>>A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 >>>>C,D:1000 \ VTloc:Z VTpeer:W VTloc:Y VTpeer:X / A,B:1000 >>>>VTloc:W \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ VTloc:X >>>>VTpeer:Z \ / VTpeer:Y >>>>C-ECHOED \ / C-ECHOED >>>> \--------------------\ /--------------------/ >>>> \/ >>>> /\ >>>> / \ >>>> >>>> >>>> >>>> >>>What have I done wrong to this point? >>> >>> >>> >>He was illustrating what you are advocating, not looking in the INIT >>and INIT-ACK.. if you do look in the INIT, then at you will >>have populated the tie-tags since you would have recognized the >>associations as being related (you would have found C in the the >>INIT's list of addresses .. the one from D.. and then you would >>have found the TCB that sent the INIT to C...) >> >> > >But the tie-tags are not to be populated in COOKIE-WAIT states (according >to RFC 2960 section 5.2.2) and in COOKIE-WAIT, COOKIE-ECHOED or >SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New text for Section >5.2.2) > > Hmm.. maybe they should be populated especially if you sent the INIT-ACK back to the same place that you sent the INIT... I need to think about this case... >Now you are telling me they should be populated? If they are populated >and D is X (the attacker) then you will have surrendered the VT of the >existing TCB to the attacker. > > No, you send the INIT-ACK back to the original place you sent the INIT (as you just corrected me up above).. in such a case if D were X you would be sending the INIT-ACK back to C and you would not be giving anything away.. >So are you saying that I have done the wrong thing by putting zero in the >tie-tags? Then is RFC 2960 section 5.2.2 and IG 08 section 2.6 new text >for 5.2.2 in error? > > No, but I begin to wonder if maybe we should not do it this way... aka you send back the INIT-ACK to where you sent the orginal INIT AND you populate the tie-tags when you are in COOKIE-WAIT state. Since you would not be revealing anything to anyone else but who you sent the INIT to anyway... let me think on this one for a while but I am pretty sure that is why we did not send tie-tags in COOKIE-WAIT and if thats the case... with the new provisions of 2.6 IG it might be ok... We might want to think about this for COOKIE_ECHOED as well... Need to mull on this one for a bit.. >I would seriously like to know what I've done wrong up to this point. > >Your statements of what I have done wrong are not consistent with either >the RFC or the IG.... Please take a closer look at it and tell me where >I have gone astray. > No, I was not paying attention and was thinking of the INIT-ACK case... R > >--brian > > > >>>(Note that I have not looked at the source address list in the INIT.) >>> >>> >>> >>> >>Yep and that is why your association will not come up when it should.. >> >> > >But I have following the RFC and Section 2.6 to the letter (except for >the C/D thing which doesn't change the result here.) > >--brian > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Sun Mar 9 08:43:04 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15486 for ; Sun, 9 Mar 2003 08:43:02 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h29DVrhs001693; Sun, 9 Mar 2003 05:31:54 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEG97075; Sun, 9 Mar 2003 05:31:52 -0800 (PST) Message-ID: <3E6B4247.70005@cisco.com> Date: Sun, 09 Mar 2003 07:31:51 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030308133044.A32275@openss7.org> <3E6A9219.50801@cisco.com> <20030308201348.A5946@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Sat, 08 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian F. G. Bidulock wrote: >> >> >> >>>Ivan, >>> >>>On Sat, 08 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: >>> >>> >>> >>> >>>>Host A/B Host C/D >>>> >>>>TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >>>>A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 >>>>C:1000 \ / B:1000 >>>>VTloc:W \ / VTloc:X >>>>VTpeer:0 \ / VTpeer:0 >>>>C-WAIT \ / C-WAIT >>>> \--------------------\ /--------------------/ >>>> \/ >>>> /\ >>>> / \ >>>> <-------------------------/ \-------------------------> >>>> >>>> >>>> >>>> >>>Populating tie-tags with zero is correct? (IG 2.6) >>> >>> >>> >>What tie-tags? so far I see a INIT being sent above.. >> >> > >In the INIT-ACK being formulated at this point... > > > >> >> >> >> >>>Sending the INIT-ACK to C or D is moot (because it is sent to D >>>if the INIT arrived just before sending the INIT from A.) >>> >>> >>> >>> >>What does your statement have to do with anything.. you >>send a INIT to C (from A) and all of a sudden you get a >>INIT from D... you have NO idea that C and D are the same >>endpoint... so you MUST send back a INIT-ACK to D... >> >> > >Huh? Is the new text in section 2.6 for section 5.2.1 in error? >It tells me that in COOKIE-WAIT state I must send the INIT-ACK back >to the same address that the original INIT (sent by this endpoint) >was sent to. > >Yet you tell me I MUST send it to D? I'm glad you don't have a >problem with me sending it to D (per RFC 2960) instead of to C >(per IG 08 2.6). > > > >>> >>> >>> >>> >>>> \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:Z / >>>> \ B:1000->D:1000 C:1000->A:1000 / >>>> \ VTloc:Y VTpeer:X VTloc:Z VTpeer:W / >>>> \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ >>>> \ / >>>> \ / >>>> \--------------------\ /--------------------/ >>>> \/ >>>> /\ >>>> / \ >>>> <-------------------------/ \-------------------------> >>>> >>>> >>>> >>>> >>>The host just copies the INIT-ACK info and echoes the cookie. >>> >>> >>> >>> >>> >>>>TCB \ COOKIE ECHO VT:Z COOKIE ECHO VT:Y / TCB >>>>A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 >>>>C,D:1000 \ VTloc:Z VTpeer:W VTloc:Y VTpeer:X / A,B:1000 >>>>VTloc:W \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ VTloc:X >>>>VTpeer:Z \ / VTpeer:Y >>>>C-ECHOED \ / C-ECHOED >>>> \--------------------\ /--------------------/ >>>> \/ >>>> /\ >>>> / \ >>>> >>>> >>>> >>>> >>>What have I done wrong to this point? >>> >>> >>> >>He was illustrating what you are advocating, not looking in the INIT >>and INIT-ACK.. if you do look in the INIT, then at you will >>have populated the tie-tags since you would have recognized the >>associations as being related (you would have found C in the the >>INIT's list of addresses .. the one from D.. and then you would >>have found the TCB that sent the INIT to C...) >> >> > >But the tie-tags are not to be populated in COOKIE-WAIT states (according >to RFC 2960 section 5.2.2) and in COOKIE-WAIT, COOKIE-ECHOED or >SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New text for Section >5.2.2) > >Now you are telling me they should be populated? If they are populated >and D is X (the attacker) then you will have surrendered the VT of the >existing TCB to the attacker. > >So are you saying that I have done the wrong thing by putting zero in the >tie-tags? Then is RFC 2960 section 5.2.2 and IG 08 section 2.6 new text >for 5.2.2 in error? > >I would seriously like to know what I've done wrong up to this point. > >Your statements of what I have done wrong are not consistent with either >the RFC or the IG.... Please take a closer look at it and tell me where >I have gone astray. > After thinking on this a bit more and re-reading the IG and the original RFC... I think the following changes are in order: 1) For the IG 2.6, as I said earlier, we need to change the wording in the IG to not send the "adding new address" error cause in the ABORT sent. This way, as Brian points out, we will not be revealing info to the attacker.. we may want to take Ivan's approach where we send the INIT-ACK back to one of the existing addresses... the down side of this is as Brian pointed out, by not getting information back, if it is an attacker, the attacker can deduce that an association exists.. (I will ask Steve on this point as well)... 2) For the same section in the IG we need to populate the tie-tags in the COOKIE-WAIT state as well, not just the COOKIE-ECHOED state as is currently in RFC2960. With the current changes in the IG (as Brian pointed out... you send back to the place you sent the INIT to) there is no danger of revealing your VT to a mallicious hacker in this case... 3) We may need a requirement that you MUST validate addresses and not solely depend on the uniquness of the V-Tags... otherwise you weaken security... I will discuss this one with Steve Bellovin in S.F. and see what he has to say... R > >--brian > > > >>>(Note that I have not looked at the source address list in the INIT.) >>> >>> >>> >>> >>Yep and that is why your association will not come up when it should.. >> >> > >But I have following the RFC and Section 2.6 to the letter (except for >the C/D thing which doesn't change the result here.) > >--brian > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-2.cisco.com Sun Mar 9 16:20:29 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08224 for ; Sun, 9 Mar 2003 16:20:27 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h29LFmEY015244 for ; Sun, 9 Mar 2003 13:15:48 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h29LFlN1024769 for ; Sun, 9 Mar 2003 13:15:47 -0800 (PST) Received: from gw.openss7.com (IDENT:S9r+FRXP+7w8nHL1YWDgeIqjHvH3vwNu@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h29LG5of000873 for ; Sun, 9 Mar 2003 13:16:05 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:hXbXYklt2dMIBcCDBhjXJtkH6amrLmkU@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h29L8JD31289; Sun, 9 Mar 2003 14:08:19 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h29L8JE28541; Sun, 9 Mar 2003 14:08:19 -0700 Date: Sun, 9 Mar 2003 14:08:18 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030309140818.A25482@openss7.org> Reply-To: bidulock@openss7.org References: <20030308133044.A32275@openss7.org> <3E6A9219.50801@cisco.com> <20030308201348.A5946@openss7.org> <3E6B3EB5.70405@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E6B3EB5.70405@cisco.com>; from rrs@cisco.com on Sun, Mar 09, 2003 at 07:16:37AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, Here's what I doing differently (but I still think that you owe me and the OpenSS7 implementation an apology): When sending the INIT-ACK the implementation is choosing a new verification tag instead of using the verification tag of the existing TCB. But the implementation also follows the RFC in that the INIT-ACK is sent back to the source of the INIT. If the VT from the TCB was sent, it would be handed to the attacker (in the initiate tag rather than tie-tags). The OpenSS7 implementation sacrifices the collision case (rare) to protect all other association initializations. The IG is not normative. This is why I asked on tsvwg why it had not been advanced. There are many clauses in the IG that are clarifications and interpretations of RFC 2960 and can be implemented without the IG being normative, but 2.6 is not one of them. RFC 2960 tells me that I MUST send the INIT-ACK back to the source of the INIT. To follow 2.6 I need to find the existing TCB to use the VT from the TCB in the initiate tag of the INIT-ACK and send the INIT-ACK to C instead of D. But this still does not justify the statement in 2.18, because it is only necessary to consider the source address list in the INIT iff there exists one or more TCBs for the port pair and local address, and iff one ore more of those TCBs is in the COOKIE-WAIT state, (i.e. only if a collision indeed can exist). It is certainly not necessary to consider and arbitrarily long and suspect source address list on all INITs, or even on INITs where there is no TCB for the port pair and destination address, or even on INITs where there is no TCB for the port pair and destination address in the COOKIE-WAIT state. To consider an arbitrarily long and suspect source address list on all INITs would open an implementation up to DoS attacks with long source address lists. So I still think that the new paragraph D) in IG 2.18 is unwarranted. It is OK to let implementations search how they will as long as they meet the other requirements. I will illustrate the need for the "extra" COOKIE-ECHO to limit a DoS attack for the INIT-ACK case to address Caitlin's example in a separate mail. I will also address in a separate mail the new text for section 5.2.1 in section 2.6. There, I believe that it is unnecessary for the receiver of an INIT to reject it just because it includes new addresses when the packet source address of the INIT is one of the existing addresses of the TCB. Also, that to not send an INIT-ACK again opens a DoS attack (where the existing TCB in the COOKIE-ECHOED state is for an association to a malicous endpoint). Please consider that--just maybe--I know what I'm talking about (yes, I can right sometimes ;), and please skip the attacks and innuendos on both myself and the OpenSS7 implementations. --brian On Sun, 09 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >Randall, > > > >On Sat, 08 Mar 2003, Randall Stewart (cisco) wrote: > > > > > > > >>Brian F. G. Bidulock wrote: > >> > >> > >> > >>>Ivan, > >>> > >>>On Sat, 08 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > >>> > >>> > >>> > >>> > >>>>Host A/B Host C/D > >>>> > >>>>TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB > >>>>A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 > >>>>C:1000 \ / B:1000 > >>>>VTloc:W \ / VTloc:X > >>>>VTpeer:0 \ / VTpeer:0 > >>>>C-WAIT \ / C-WAIT > >>>> \--------------------\ /--------------------/ > >>>> \/ > >>>> /\ > >>>> / \ > >>>> <-------------------------/ \-------------------------> > >>>> > >>>> > >>>> > >>>> > >>>Populating tie-tags with zero is correct? (IG 2.6) > >>> > >>> > >>> > >>What tie-tags? so far I see a INIT being sent above.. > >> > >> > > > >In the INIT-ACK being formulated at this point... > > > > > > > >> > >> > >> > >> > >>>Sending the INIT-ACK to C or D is moot (because it is sent to D > >>>if the INIT arrived just before sending the INIT from A.) > >>> > >>> > >>> > >>> > >>What does your statement have to do with anything.. you > >>send a INIT to C (from A) and all of a sudden you get a > >>INIT from D... you have NO idea that C and D are the same > >>endpoint... so you MUST send back a INIT-ACK to D... > >> > >> > > > >Huh? Is the new text in section 2.6 for section 5.2.1 in error? > >It tells me that in COOKIE-WAIT state I must send the INIT-ACK back > >to the same address that the original INIT (sent by this endpoint) > >was sent to. > > > >Yet you tell me I MUST send it to D? I'm glad you don't have a > >problem with me sending it to D (per RFC 2960) instead of to C > >(per IG 08 2.6). > > > > > > I had forgotten about that addition... and actually it is the right thing > to do as well... This way if you did get a evil attacker sending in > from 'E' as you painted in one of the other emails would not > get the INIT-ACK back... and the peer at C/D would discard > it... > > I will have to go check our implementation and see if we did this... > if not we will get a patch out right away :> > > > > > > > >>> > >>> > >>> > >>> > >>>> \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:Z / > >>>> \ B:1000->D:1000 C:1000->A:1000 / > >>>> \ VTloc:Y VTpeer:X VTloc:Z VTpeer:W / > >>>> \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ > >>>> \ / > >>>> \ / > >>>> \--------------------\ /--------------------/ > >>>> \/ > >>>> /\ > >>>> / \ > >>>> <-------------------------/ \-------------------------> > >>>> > >>>> > >>>> > >>>> > >>>The host just copies the INIT-ACK info and echoes the cookie. > >>> > >>> > >>> > >>> > >>> > >>>>TCB \ COOKIE ECHO VT:Z COOKIE ECHO VT:Y / TCB > >>>>A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 > >>>>C,D:1000 \ VTloc:Z VTpeer:W VTloc:Y VTpeer:X / A,B:1000 > >>>>VTloc:W \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ VTloc:X > >>>>VTpeer:Z \ / VTpeer:Y > >>>>C-ECHOED \ / C-ECHOED > >>>> \--------------------\ /--------------------/ > >>>> \/ > >>>> /\ > >>>> / \ > >>>> > >>>> > >>>> > >>>> > >>>What have I done wrong to this point? > >>> > >>> > >>> > >>He was illustrating what you are advocating, not looking in the INIT > >>and INIT-ACK.. if you do look in the INIT, then at you will > >>have populated the tie-tags since you would have recognized the > >>associations as being related (you would have found C in the the > >>INIT's list of addresses .. the one from D.. and then you would > >>have found the TCB that sent the INIT to C...) > >> > >> > > > >But the tie-tags are not to be populated in COOKIE-WAIT states (according > >to RFC 2960 section 5.2.2) and in COOKIE-WAIT, COOKIE-ECHOED or > >SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New text for Section > >5.2.2) > > > > > Hmm.. maybe they should be populated especially if you sent the > INIT-ACK back to the same place that you sent the INIT... I need > to think about this case... > > > >Now you are telling me they should be populated? If they are populated > >and D is X (the attacker) then you will have surrendered the VT of the > >existing TCB to the attacker. > > > > > No, you send the INIT-ACK back to the original place you sent > the INIT (as you just corrected me up above).. in such a case > if D were X you would be sending the INIT-ACK back to > C and you would not be giving anything away.. > > > >So are you saying that I have done the wrong thing by putting zero in the > >tie-tags? Then is RFC 2960 section 5.2.2 and IG 08 section 2.6 new text > >for 5.2.2 in error? > > > > > No, but I begin to wonder if maybe we should not do it this way... aka > you send back the INIT-ACK to where you sent the orginal INIT > AND you populate the tie-tags when you are in COOKIE-WAIT state. > Since you would not be revealing anything to anyone else but who > you sent the INIT to anyway... let me think on this one for a while > but I am pretty sure that is why we did not send tie-tags in COOKIE-WAIT > and if thats the case... with the new provisions of 2.6 IG it might be > ok... > > We might want to think about this for COOKIE_ECHOED as well... > Need to mull on this one for a bit.. > > > > >I would seriously like to know what I've done wrong up to this point. > > > >Your statements of what I have done wrong are not consistent with either > >the RFC or the IG.... Please take a closer look at it and tell me where > >I have gone astray. > > > No, I was not paying attention and was thinking of the INIT-ACK case... > > R > > > > > >--brian > > > > > > > >>>(Note that I have not looked at the source address list in the INIT.) > >>> > >>> > >>> > >>> > >>Yep and that is why your association will not come up when it should.. > >> > >> > > > >But I have following the RFC and Section 2.6 to the letter (except for > >the C/D thing which doesn't change the result here.) > > > >--brian > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Sun Mar 9 17:48:59 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22549 for ; Sun, 9 Mar 2003 17:48:56 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h29Mk50E021704 for ; Sun, 9 Mar 2003 14:46:06 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h29Mk5cs020293 for ; Sun, 9 Mar 2003 14:46:05 -0800 (PST) Received: from gw.openss7.com (IDENT:d4V/OcNLyPc8N9GvlvLPO4fkUmghNwCw@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h29Mi8IA014139 for ; Sun, 9 Mar 2003 14:44:08 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:xy/CQSUbUV3c663aA9lvOCWZ8GIO5bDW@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h29McoD32366; Sun, 9 Mar 2003 15:38:50 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h29McoU29762; Sun, 9 Mar 2003 15:38:50 -0700 Date: Sun, 9 Mar 2003 15:38:50 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Caitlin Bestler , sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030309153850.B25482@openss7.org> Reply-To: bidulock@openss7.org References: <20030303103316.B15597@openss7.org> <20030308025453.A26345@openss7.org> <3E69DE4D.8010609@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E69DE4D.8010609@cisco.com>; from rrs@cisco.com on Sat, Mar 08, 2003 at 06:13:01AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Sat, 08 Mar 2003, Randall Stewart (cisco) wrote: > Brian: > > One key thing I don't think I understand in your scenario below... something > Steve Bellovin once commented upon to me.. > > Why are you establishing an association to a malicious host? > > Its one thing when you are a passiver server... but it is quite > another when YOU choose to make this establishement to > a malicious host... > > I would classify this as way beyond a corner case ... > > Its quite likely to have a collision case.. where both attempt > to contact at the same time.. but you making the > connections by your choice to a good host and a malicious > host seem a bit over the top... Malicious web servers exist in the wild. Two points: 1) For a general purpose protocol, one should not make assumptions about the probability of certain events, because to do so makes assumptions about the application. (I think it was You, Ivan or Caitlin that told me this.) I can tell you that for any current IETF applications, Caitlin's example will not occur (because it relies upon static port allocation on both peers and misconfiguration (SO_REUSEADDR) on the peer launching multiple INITs). You and Ivan tell me on one hand that saying that the situation will not occur or will occur with only extremely low probabiliy is not good enough, and that sending an "extra" packet in this low probability situation is also not good enough, but now you say that it is good enough to have a vulnerability because it is low probability? I think, quite the reverse, that a corner case with a vulnerability deserves far more attention than a corner case with what seems on the surface to be an "extra" packet. Attached is an analysis of why sending the "extra" COOKIE-ECHO actually limits the attack but does not solve it. To solve it requires that Host A has prior knowledge of the addresses belonging to the endpoint to which it launches the INIT. 2) It is naive when considering security to assume that just because you are launching an INIT to an endpoint that it can be trusted, especially on the Internet. Do you want your transport protocol to place trust in every web server that you browse? I think not. So I don't think that it is over the top at all. > > If you want to look at this case.. what about > > ----------INIT from A:1000 to X:1000--------------------> > <---------INIT-ACK from X:1000 to A:1000 (IP-X,IP-B)--- > paint below, you can't establish to Host B in fact > the app THINK's it is already talking to B > once the rest of the association comes up> Precisely. Address X has been verified to some level of confidence. X actually returned the proper VT to the proper, destination address with the proper port pair. But the source address list has not been verified. If action is taken on the source address list that affects whether those addresses will be accepted from the legitimate hosts that own them, then the protocol is naive and vulnerable to attack. See below for a detailed attack. > > I can't see how you would be concerned about the > case below and not care about the same scenario > with just a bit of different message ordering... Actually I am concerned about both message orderings of the INIT. See the example below where the message ordering is as you show above. > > So I don't see the merit in your argument and I think Caitlin's > comments on extra network traffic are still not addressed by your > comments below... especially since you are arguing from an extreme > corner case... See the more detailed argument below as to how the "extra" COOKIE-ECHO limits the vulnerability, but does not solve it. Solving the vulnerability requires that A know the addresses of multi-homed hosts to which it launches an init. (This is not too unrealistic: DNS can return multiple IP addresses for a given host name, and DNS is the normal way that an application discovers IP addresses to send the INIT in the first place.) Here's the argument: Host A/B Host X Host C/D | | | |INIT A:1000 -> X:1000 | | |---------------------------------------------->| | |TCB1: | | |VT: X | | |PT: 0 | | |Loc: A:1000 | | |Rem: X:1000 | | |State: COOKIE-WAIT | | | | | |INIT A:1000 -> C:1000 | | |------------------------------------------------------->| |TCB2: | | |VT: Y | | |PT: 0 | | |Loc: A:1000 | | |Rem: C:1000 | | |State: COOKIE-WAIT | | | | | | INIT-ACK X:1000 -> A:1000 (D)| | |<----------------------------------------------| | |(TCB2 cannot be found on source addr list) | | |(TCB1 is found) | | | | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | |TCB1: | | |VT: X | | |PT: W | | |Loc: A:1000 | | |Rem: X:1000, D:1000 | | |State: COOKIE-ECHOED | | | X does not | | | send (or delays) | | COOKIE-ACK | | | | | | INIT-ACK C:1000 -> A:1000 (D)| |<-------------------------------------------------------| | | | Did you expect Host A to not send the COOKIE-ECHO for TCB2 and error the connection attempt to the user of TCB2? The user of TCB2 will retry, resulting in: | | | |T1-cookie timeout | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | Note that X can keep the T1-cookie timeout initially high by delaying the response to the INIT by RTO.Initial. T1-cookies double with each retransmission up to 60 seconds, so the sequence is 3sec, 6sec, 12sec, 24sec, 48sec, 60sec, 60sec, 60sec which is 273 seconds or about 4 minutes. This can be extended another 30 seconds by responding with a COOKIE-ACK just before the final timeout (or just before the application times out) and keeping the association established until after 30 more seconds a HEARTBEAT is sent to D which will illicit an abort and then go around again. If the attacker does not SACK any received data then Host A may heartbeat X before D, or X could add several of bogus addresses into the list that will be heartbeated before D. Since T3-rtx is held at 60 seconds, X can get an average of 2 minutes out of each bogus destination in the source address list. The application may timeout before that but the timeouts of Internet applications are well known. | | | |T1-cookie timeout | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | | | | |INIT A:1000 -> C:1000 | | |------------------------------------------------------->| |TCB2: | | |VT: Y | | |PT: 0 | | |Loc: A:1000 | | |Rem: C:1000 | | |State: COOKIE-WAIT | | | INIT-ACK C:1000 -> A:1000 (D)| |<-------------------------------------------------------| Refused, because TCB exists for A:1000<-->D:1000? | | | |T1-cookie timeout | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | | | | |T1-cookie timeout | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | | . | | | . repeat | | | . | | Note that X can find the address to include in its INIT merely by sending an INIT to C or D and getting an INIT-ACK. If the INIT-ACK is not refused, and a COOKIE-ECHO is returned (the "extra" packet), the following occurs: Host A/B Host X Host C/D | | | |INIT A:1000->X:1000 | | |---------------------------------------------->| | |TCB1: | | |VT: X | | |PT: 0 | | |Loc: A:1000 | | |Rem: X:1000 | | |State: COOKIE-WAIT | | | | | |INIT A:1000->C:1000 | | |------------------------------------------------------->| |TCB2: | | |VT: Y | | |PT: 0 | | |Loc: A:1000 | | |Rem: C:1000 | | |State: COOKIE-WAIT | | | | | | INIT-ACK X:1000->A:1000 (D)| | |<----------------------------------------------| | |(TCB2 cannot be found on source addr list) | | |(TCB1 is found) | | | | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | |TCB1: X does not | | |VT: X send (or delays) | |PT: W COOKIE-ACK | | |Loc: A:1000 | | |Rem: X:1000, D:1000 | | |State: COOKIE-ECHOED | | | INIT-ACK C:1000->A:1000 (D)| |<-------------------------------------------------------| | | | |COOKIE-ECHO A:1000->C:1000 | | |------------------------------------------------------->| |TCB2: | | |VT: X | | |PT: Z | | |Loc: A:1000 | | |Rem: C:1000, D:1000 | | |State: COOKIE-ECHOED | | | COOKIE-ACK C:1000->A:1000| |<-------------------------------------------------------| |TCB2: | | |VT: X | | |PT: Z | | |Loc: A:1000 | | |Rem: C:1000, D:1000 | | |State: ESTABLISHED | | | | | |(Discard TCB1, inform user) (attacker thwarted)| | | | | What this would do is force attacker X to reply quickly with a COOKIE-ACK in order to block the legitimate host as in: Host A/B Host X Host C/D | | | |INIT A:1000->X:1000 | | |---------------------------------------------->| | |TCB1: | | |VT: X | | |PT: 0 | | |Loc: A:1000 | | |Rem: X:1000 | | |State: COOKIE-WAIT | | | | | |INIT A:1000->C:1000 | | |------------------------------------------------------->| |TCB2: | | |VT: Y | | |PT: 0 | | |Loc: A:1000 | | |Rem: C:1000 | | |State: COOKIE-WAIT | | | | | | INIT-ACK X:1000->A:1000 (D)| | |<----------------------------------------------| | |(TCB2 cannot be found on source addr list) | | |(TCB1 is found) | | | | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | |TCB1: | | |VT: X | | |PT: W | | |Loc: A:1000 | | |Rem: X:1000, D:1000 | | |State: COOKIE-ECHOED | | | INIT-ACK C:1000->A:1000 (D)| |<-------------------------------------------------------| | | | | COOKIE-ACK X:1000->A:1000| | |<----------------------------------------------| | |TCB1: | | |VT: X | | |PT: W | | |Loc: A:1000 | | |Rem: X:1000, D:1000 | | |State: ESTABLISHED | | | | | |(Discard TCB2, inform user) | | | | | What this serves to do is put the attacker immediately into the ESTABLISHED state. If the attacker delays the COOKIE-ACK, the the legitimate peer will win the race and the attack is thwarted. The attacker cannot block for the initial 4 minutes, but can still place bogus addresses in the address list that will extend the period of time before a HEARTBEAT/ABORT sequence to D takes the association down. The major difference is that, in the ESTABLISHED state, the user of TCB1 can challenge the peer. In the COOKIE-ECHOED state, the user of TCB1 is blocked from communicating on the association and the ULP cannot assist in detecting the attack. Because X and D are indistinguishable to "A" ("A" has no prior knowledge of D or X), the only way to limit the attack is by sending the "extra" COOKIE-ECHO. So for the sake of security in this case, whether it be rare or not, it is better to send the extra COOKIE-ECHO than not. Taking actions on unverifiable addresses in the source address list of INIT-ACKs is IMO quite naive. It opens the protocol up to an entire spectrum of addresss spoofing attacks. The only source address that is verified in INIT and INIT-ACK are the packet header source addresses. (The INIT packet source addres is verified by HMAC on COOKIE-ECHO; the INIT-ACK source address is verified by port pair, destination address and VT of the INIT-ACK matching those of the INIT.) The reason that 2.6 in the COOKIE-WAIT state works for collision is because the INIT-ACK with the existing VT is sent to the same address as the INIT. The receiver of the INIT already has the VT from the INIT so sending it in the INIT-ACK to same address does not expose the VT. In ths case, it is not possible for "A" to determine whether D truly belongs to X or whether it truly belongs to C without prior knowledge of address D. In the case where knowledge of address D can be easily obtained (e.g. DNS query), "A" is even the more vulnerable to X if it does not utilize the same readily available information about D. This is really scary. Server X can easily discover the secondary addresses service to which it wishes to block access by launching INITs to them and getting INIT-ACKs. Then server X can place _all_ the secondardy addresses in the address list (say 200 of them). The one way that I can see to block the attack is by not permitting sockets bound to a static port address with SO_REUSEADDR to have their TCBs expanded by the INIT-ACK beyond the addresses that were supplied to connect() iff any other TCB is bound to the same static address (i.e., if resuse is actually in effect, for our imp that means if the bind bucket is not marked for fastreuse). Then the attack cannot form, and neither association will form unless sufficient prior knowledge was supplied to at least one of the two connect()s. This is certainly not too strong a restriction to place on socket users. This also means that the "extra" COOKIE-ECHO would never occur because the INIT-ACK can be refused on the basis of the bind characteristics. I still don't need to examine the address list when searching for a matching TCB, because any action taken on the address list is vulnerable to attack. The address list has not been verified. The only use for the packet source address in the INIT is to know where to send (in the collision corner case) the INIT-ACK, and to populate the cookie. The only use for the packet source address and source address list in the INIT-ACK is to expand unexpanded TCBs. (In this case, if sufficient address information is not supplied I will refuse to expand the TCB.) I hope this illustrates why it is unecessary (and is a secuirty risk) to examine the source address list of INIT-ACK. I will talk to the "new addresses" of section 2.6 in a separate mail. (This one is already way too long ;) --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-2.cisco.com Sun Mar 9 19:50:25 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15271 for ; Sun, 9 Mar 2003 19:50:22 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2A0kbEY029154; Sun, 9 Mar 2003 16:46:37 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEH12635; Sun, 9 Mar 2003 16:46:35 -0800 (PST) Message-ID: <3E6BE06A.4070207@cisco.com> Date: Sun, 09 Mar 2003 18:46:34 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030308133044.A32275@openss7.org> <3E6A9219.50801@cisco.com> <20030308201348.A5946@openss7.org> <3E6B3EB5.70405@cisco.com> <20030309140818.A25482@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >Here's what I doing differently (but I still think that you owe >me and the OpenSS7 implementation an apology): > > I fail to see why I would owe any implementation a apology.. the spec is the spec.. we are discussing issues with it and I hope in the end it is stronger security wise as well as a document. Our discussions have, for example, highlighted where the BSD implementation did not send back to the INIT-ACK to where the original INIT was sent.. this is a security weakness and it is good that this discussion uncovered my error :-) >When sending the INIT-ACK the implementation is choosing a new >verification tag instead of using the verification tag of the >existing TCB. But the implementation also follows the RFC in >that the INIT-ACK is sent back to the source of the INIT. If >the VT from the TCB was sent, it would be handed to the attacker >(in the initiate tag rather than tie-tags). > Not if one sends it back per the IG 2.6 to the original place one sent the INIT.. this is the whole reason for the wording in the IG (and a subtle point I had missed in the BSD stack.. it will be fixed in a patch by tommorrow)... >The OpenSS7 >implementation sacrifices the collision case (rare) to protect >all other association initializations. > > This is not as rare of case as you think. I know at least one implementation that is always attempting to bring up an association with a peer... when the two of these are put together I actually saw DATA on the COOKIE-ACK, which I really did not think likely.. of course this implementations/application almost ALWAYS went through this very collision scenario you depict.. since when one machine is down the other is sending INIT's on a regular basis.. the other one comes up and the first thing it does is send a INIT.. presto you have this scenario.. it is not uncommon.. the wording lack, as I remember it, was found in a bakeoff and we were NOT testing this condition.. it is far more common then you think... >The IG is not normative. This is why I asked on tsvwg why it >had not been advanced. There are many clauses in the IG that >are clarifications and interpretations of RFC 2960 and can be >implemented without the IG being normative, but 2.6 is not one >of them. RFC 2960 tells me that I MUST send the INIT-ACK back >to the source of the INIT. > And that MUST was not written thinking of the collision cases. The IG 2.6 is correct and normative. It clearify's that when you are setting up an association and then receive a INIT (the collision case) you then send the INIT-ACK back to where you sent the INIT.. this is correct and we should have caught it when we wrote RFC2960.. but like many things we missed issues.. this was one.. I think if you follow the advise of the IG there is no problem.. and there is nothing non-normative about this section... > >To follow 2.6 I need to find the existing TCB to use the VT from >the TCB in the initiate tag of the INIT-ACK and send the >INIT-ACK to C instead of D. > Thats correct.. which means you have to look in the INIT for the addresses so you can do the proper matching of the association.. this was ALWAYS the intention when we wrote RFC2960.. > But this still does not justify the >statement in 2.18, because it is only necessary to consider the >source address list in the INIT iff there exists one or more >TCBs for the port pair and local address, and iff one ore more >of those TCBs is in the COOKIE-WAIT state, (i.e. only if a >collision indeed can exist). It is certainly not necessary to >consider and arbitrarily long and suspect source address list on >all INITs, or even on INITs where there is no TCB for the port > How could you ever tell what state you were in unless you check all the addresses? You would NEVER have any way to know. There are other "corner cases" (as you call them, not I) that checking the INIT/INIT-ACK covers.. at least three of them have been presented to you. >pair and destination address, or even on INITs where there is no >TCB for the port pair and destination address in the COOKIE-WAIT >state. To consider an arbitrarily long and suspect source >address list on all INITs would open an implementation up to >DoS attacks with long source address lists. > > It is easy and cheap to check the source address list to see if you have a TCB.. As Caitlin as pointed out, one can do this with a properly written data structure without locking. Once this is in place it takes far more cycles to do the SHA-1 signing.. Besides you can't look only some of the time.. you have to do it all of the time .. since an implementation cannot possibly know if it has a TCB unless it checks the addresses... >So I still think that the new paragraph D) in IG 2.18 is >unwarranted. It is OK to let implementations search how they >will as long as they meet the other requirements. > > You have to check the INIT period for those addresses... there is no other way to find the association that is forming and there is no way to know if one is forming unless you check... >I will illustrate the need for the "extra" COOKIE-ECHO to limit >a DoS attack for the INIT-ACK case to address Caitlin's example >in a separate mail. > > If an implementation feels it is under a DOS attack it can stop responding to cookies, limit cookie responses (just like one does with ICMP) and several other scenarios... >I will also address in a separate mail the new text for section >5.2.1 in section 2.6. There, I believe that it is unnecessary >for the receiver of an INIT to reject it just because it includes >new addresses when the packet source address of the INIT is one >of the existing addresses of the TCB. > That procedure has been in the IG for a long time.. and it does make sense... except the issue of sending back the abort with cause.. a regular abort should do fine.. or I see possibly using Ivan's idea.. but like I said I wish to talk to a security expert about this... aka Steve Bellovin. It is good that you pointed this out... > Also, that to not send an >INIT-ACK again opens a DoS attack (where the existing TCB in the >COOKIE-ECHOED state is for an association to a malicous endpoint). > > Not necessarily.. one can send a ABORT for any number of reasons when an INIT arrives.. no listner is one of the most likely scenarios... leave out the error cause and you would not have any way of knowing if there is even a listner on a port or not.. >Please consider that--just maybe--I know what I'm talking about >(yes, I can right sometimes ;), and please skip the attacks and >innuendos on both myself and the OpenSS7 implementations. > > I have never attacked either you or your implementation.. you do seem to be good at attacking me and every one else as well that disagrees with you. If I was not willing to listen to you I would not have responded to your emails. Only when you seem to have topics worth exploring do I respond. If you refer to my pasting code in.. you are also welcome to paste in code from my implementation.. there will definetly be bugs.. all implementations have them... I have one to fix right now to make the BSD implemention conformant to the IG section 2.6. :-0 R >--brian > >On Sun, 09 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian F. G. Bidulock wrote: >> >> >> >>>Randall, >>> >>>On Sat, 08 Mar 2003, Randall Stewart (cisco) wrote: >>> >>> >>> >>> >>> >>>>Brian F. G. Bidulock wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Ivan, >>>>> >>>>>On Sat, 08 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Host A/B Host C/D >>>>>> >>>>>>TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >>>>>>A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 >>>>>>C:1000 \ / B:1000 >>>>>>VTloc:W \ / VTloc:X >>>>>>VTpeer:0 \ / VTpeer:0 >>>>>>C-WAIT \ / C-WAIT >>>>>> \--------------------\ /--------------------/ >>>>>> \/ >>>>>> /\ >>>>>> / \ >>>>>> <-------------------------/ \-------------------------> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Populating tie-tags with zero is correct? (IG 2.6) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>What tie-tags? so far I see a INIT being sent above.. >>>> >>>> >>>> >>>> >>>In the INIT-ACK being formulated at this point... >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Sending the INIT-ACK to C or D is moot (because it is sent to D >>>>>if the INIT arrived just before sending the INIT from A.) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>What does your statement have to do with anything.. you >>>>send a INIT to C (from A) and all of a sudden you get a >>>>INIT from D... you have NO idea that C and D are the same >>>>endpoint... so you MUST send back a INIT-ACK to D... >>>> >>>> >>>> >>>> >>>Huh? Is the new text in section 2.6 for section 5.2.1 in error? >>>It tells me that in COOKIE-WAIT state I must send the INIT-ACK back >>>to the same address that the original INIT (sent by this endpoint) >>>was sent to. >>> >>>Yet you tell me I MUST send it to D? I'm glad you don't have a >>>problem with me sending it to D (per RFC 2960) instead of to C >>>(per IG 08 2.6). >>> >>> >>> >>> >>I had forgotten about that addition... and actually it is the right thing >>to do as well... This way if you did get a evil attacker sending in >>from 'E' as you painted in one of the other emails would not >>get the INIT-ACK back... and the peer at C/D would discard >>it... >> >>I will have to go check our implementation and see if we did this... >>if not we will get a patch out right away :> >> >> >> >> >>> >>> >>> >>> >>>>> >>>>> >>>>> >>>>> >>>>>> \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:Z / >>>>>> \ B:1000->D:1000 C:1000->A:1000 / >>>>>> \ VTloc:Y VTpeer:X VTloc:Z VTpeer:W / >>>>>> \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ >>>>>> \ / >>>>>> \ / >>>>>> \--------------------\ /--------------------/ >>>>>> \/ >>>>>> /\ >>>>>> / \ >>>>>> <-------------------------/ \-------------------------> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>The host just copies the INIT-ACK info and echoes the cookie. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>TCB \ COOKIE ECHO VT:Z COOKIE ECHO VT:Y / TCB >>>>>>A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 >>>>>>C,D:1000 \ VTloc:Z VTpeer:W VTloc:Y VTpeer:X / A,B:1000 >>>>>>VTloc:W \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ VTloc:X >>>>>>VTpeer:Z \ / VTpeer:Y >>>>>>C-ECHOED \ / C-ECHOED >>>>>> \--------------------\ /--------------------/ >>>>>> \/ >>>>>> /\ >>>>>> / \ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>What have I done wrong to this point? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>He was illustrating what you are advocating, not looking in the INIT >>>>and INIT-ACK.. if you do look in the INIT, then at you will >>>>have populated the tie-tags since you would have recognized the >>>>associations as being related (you would have found C in the the >>>>INIT's list of addresses .. the one from D.. and then you would >>>>have found the TCB that sent the INIT to C...) >>>> >>>> >>>> >>>> >>>But the tie-tags are not to be populated in COOKIE-WAIT states (according >>>to RFC 2960 section 5.2.2) and in COOKIE-WAIT, COOKIE-ECHOED or >>>SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New text for Section >>>5.2.2) >>> >>> >>> >>> >>Hmm.. maybe they should be populated especially if you sent the >>INIT-ACK back to the same place that you sent the INIT... I need >>to think about this case... >> >> >> >> >>>Now you are telling me they should be populated? If they are populated >>>and D is X (the attacker) then you will have surrendered the VT of the >>>existing TCB to the attacker. >>> >>> >>> >>> >>No, you send the INIT-ACK back to the original place you sent >>the INIT (as you just corrected me up above).. in such a case >>if D were X you would be sending the INIT-ACK back to >>C and you would not be giving anything away.. >> >> >> >> >>>So are you saying that I have done the wrong thing by putting zero in the >>>tie-tags? Then is RFC 2960 section 5.2.2 and IG 08 section 2.6 new text >>>for 5.2.2 in error? >>> >>> >>> >>> >>No, but I begin to wonder if maybe we should not do it this way... aka >>you send back the INIT-ACK to where you sent the orginal INIT >>AND you populate the tie-tags when you are in COOKIE-WAIT state. >>Since you would not be revealing anything to anyone else but who >>you sent the INIT to anyway... let me think on this one for a while >>but I am pretty sure that is why we did not send tie-tags in COOKIE-WAIT >>and if thats the case... with the new provisions of 2.6 IG it might be >>ok... >> >>We might want to think about this for COOKIE_ECHOED as well... >>Need to mull on this one for a bit.. >> >> >> >> >> >>>I would seriously like to know what I've done wrong up to this point. >>> >>>Your statements of what I have done wrong are not consistent with either >>>the RFC or the IG.... Please take a closer look at it and tell me where >>>I have gone astray. >>> >>> >>> >>No, I was not paying attention and was thinking of the INIT-ACK case... >> >>R >> >> >> >> >>>--brian >>> >>> >>> >>> >>> >>>>>(Note that I have not looked at the source address list in the INIT.) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Yep and that is why your association will not come up when it should.. >>>> >>>> >>>> >>>> >>>But I have following the RFC and Section 2.6 to the letter (except for >>>the C/D thing which doesn't change the result here.) >>> >>>--brian >>> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-2.cisco.com Mon Mar 10 00:38:07 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07818 for ; Mon, 10 Mar 2003 00:38:05 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2A5M8EY010486 for ; Sun, 9 Mar 2003 21:22:08 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2A5LNVH001135 for ; Sun, 9 Mar 2003 21:21:28 -0800 (PST) Received: from gw.openss7.com (IDENT:d+w/4bj0ojGe/A9JxrpzOv/gITjyhbFt@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2A5LvoU009842 for ; Sun, 9 Mar 2003 21:21:58 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:O2OKkJWKKOADX0jwPxJlqXXU+aQ+5DCH@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2A5EoD04722; Sun, 9 Mar 2003 22:14:50 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2A5EnP01712; Sun, 9 Mar 2003 22:14:49 -0700 Date: Sun, 9 Mar 2003 22:14:49 -0700 From: "Brian F. G. Bidulock" To: tsvwg@ietf.org Cc: sctp-impl@external.cisco.com Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-08.txt Message-ID: <20030309221449.A1547@openss7.org> Reply-To: bidulock@openss7.org References: <200303041230.HAA15062@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <200303041230.HAA15062@ietf.org>; from Internet-Drafts@ietf.org on Tue, Mar 04, 2003 at 07:30:07AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit I have been told by an author of this document that this document is normative. Is this the case? Could someone please point me to the place in the IETF process where a draft document is considered normative before advancing? --brian On Tue, 04 Mar 2003, 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 Transport Area Working Group Working Group of the IETF. > > Title : Stream Control Transmission Protocol (SCTP) > Implementors Guide > Author(s) : R. Stewart, L. Ong et al. > Filename : draft-ietf-tsvwg-sctpimpguide-08.txt > Pages : 64 > Date : 2003-3-3 > > This document contains a compilation of all defects found up until > the publishing of this document for the Stream Control Transmission > Protocol (SCTP) RFC2960 [3]. These defects may be of an editorial or > technical nature. This document may be thought of as a companion > document to be used in the implementation of SCTP to clarify errors > in the original SCTP document. > This document updates RFC2960 [3] and text within this document > supersedes the text found in RFC2960 [3]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-08.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > 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-tsvwg-sctpimpguide-08.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-tsvwg-sctpimpguide-08.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. -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Mon Mar 10 07:09:37 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00751 for ; Mon, 10 Mar 2003 07:09:35 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2ABSs0E001192; Mon, 10 Mar 2003 03:28:54 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEH32326; Mon, 10 Mar 2003 03:28:52 -0800 (PST) Message-ID: <3E6C76F4.4050003@cisco.com> Date: Mon, 10 Mar 2003 05:28:52 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-08.txt References: <200303041230.HAA15062@ietf.org> <20030309221449.A1547@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian: I stated to you (I think this is who you refer to) that our intention is to make it normative whenever it gets incorporated into a new RFC... You should know that all drafts are not normative until they finish the IETF process. Our discussion was in particular about text that you objected to.. my interpretation of your query was that you thought the text could never be normative... and I just don't think that is true.. since our intentions are to close the I-G soon... R Brian F. G. Bidulock wrote: >I have been told by an author of this document that this document is normative. > >Is this the case? > >Could someone please point me to the place in the IETF process >where a draft document is considered normative before advancing? > >--brian > > >On Tue, 04 Mar 2003, 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 Transport Area Working Group Working Group of the IETF. >> >> Title : Stream Control Transmission Protocol (SCTP) >> Implementors Guide >> Author(s) : R. Stewart, L. Ong et al. >> Filename : draft-ietf-tsvwg-sctpimpguide-08.txt >> Pages : 64 >> Date : 2003-3-3 >> >>This document contains a compilation of all defects found up until >>the publishing of this document for the Stream Control Transmission >>Protocol (SCTP) RFC2960 [3]. These defects may be of an editorial or >>technical nature. This document may be thought of as a companion >>document to be used in the implementation of SCTP to clarify errors >>in the original SCTP document. >>This document updates RFC2960 [3] and text within this document >>supersedes the text found in RFC2960 [3]. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-08.txt >> >>To remove yourself from the IETF Announcement list, send a message to >>ietf-announce-request with the word unsubscribe in the body of the message. >> >>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-tsvwg-sctpimpguide-08.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-tsvwg-sctpimpguide-08.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. >> >> > > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-2.cisco.com Mon Mar 10 07:52:23 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08660 for ; Mon, 10 Mar 2003 07:52:21 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2AChLEY028023 for ; Mon, 10 Mar 2003 04:43:21 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2AChKb6003582 for ; Mon, 10 Mar 2003 04:43:20 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2ACguAL010936 for ; Mon, 10 Mar 2003 04:43:02 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2ACFP117677 for ; Mon, 10 Mar 2003 14:15:25 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 14:16:46 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 14:16:46 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 14:16:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Mon, 10 Mar 2003 14:16:44 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLlsqcmjF99aN+VTgW5k0oNsKpf9gBSigyg From: To: Cc: , , X-OriginalArrivalTime: 10 Mar 2003 12:16:45.0496 (UTC) FILETIME=[EAC9A380:01C2E6FE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA08660 Brian, > > Ivan, > > On Sat, 08 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > Host A/B Host C/D > > TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB > A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 > C:1000 \ / B:1000 > VTloc:W \ / VTloc:X > VTpeer:0 \ / VTpeer:0 > C-WAIT \ / C-WAIT > \--------------------\ /--------------------/ > \/ > /\ > / \ > <-------------------------/ \-------------------------> > > Populating tie-tags with zero is correct? (IG 2.6) Yes, it is the correct thing to do. > Sending the INIT-ACK to C or D is moot (because it is sent to D > if the INIT arrived just before sending the INIT from A.) Well, the INIT could arrive after sending the COOKIE ECHO, in the ESTABLISHED state or while SHUTTING DOWN, and the actions to be taken would be different... But this is the case we are discussing, right now... > > \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:Z / > \ B:1000->D:1000 C:1000->A:1000 / > \ VTloc:Y VTpeer:X VTloc:Z VTpeer:W / > \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ > \ / > \ / > \--------------------\ /--------------------/ > \/ > /\ > / \ > <-------------------------/ \-------------------------> This is the part that is wrong... I'll explain below... > The host just copies the INIT-ACK info and echoes the cookie. > > \ INIT ACK VT:X IT:Y INIT ACK VT:W IT:Z / > \ B:1000->D:1000 C:1000->A:1000 / > \ VTloc:Y VTpeer:X VTloc:Z VTpeer:W / > \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ > \ / > \ / > \--------------------\ /--------------------/ > \/ > /\ > / \ > <-------------------------/ \-------------------------> > > What have I done wrong to this point? Ay, ay, ay, Brian... I won't blame you this time, but please, take more coffee ;-) When the INIT comes you don't recognize it as coming from the same endpoint you are trying to establish an association with, and so, you don't follow section 5.2.1 of the RFC... What you have done wrong is including a new IT in the INIT ACK, instead of using the same one you put inside your INIT... So, we should be in this situation: TCB \ COOKIE ECHO VT:X COOKIE ECHO VT:W / TCB A,B:1000 \ A:1000->C:1000 D:1000->B:1000 / C,D:1000 C,D:1000 \ VTloc:X VTpeer:W VTloc:W VTpeer:X / A,B:1000 VTloc:W \TTloc:0 TTpeer:0 TTloc:0 TTpeer:0/ VTloc:X VTpeer:X \ / VTpeer:W C-ECHOED \ / C-ECHOED \--------------------\ /--------------------/ \/ /\ / \ <-------------------------/ \-------------------------> And then, instead of dropping the COOKIE ECHO, you would accept it, and both host would open *a single association*... You would send the INIT ACK and stuff, and you would end up having one and only one association established between the two hosts... Of course, all this unless I made a mistake... > (Note that I have not looked at the source address list in the INIT.) > > --brian > > > X<-------------------------/ \------------------------->X Yes, I did notice... And that's the reason why you ended up with this situation: dropping COOKIE ECHOes and not establishing the association... BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-core-1.cisco.com Mon Mar 10 08:00:40 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10334 for ; Mon, 10 Mar 2003 08:00:38 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2ACs70E015132 for ; Mon, 10 Mar 2003 04:54:07 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2ACs7gI008482 for ; Mon, 10 Mar 2003 04:54:07 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2ACsOof007538 for ; Mon, 10 Mar 2003 04:54:25 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2ACgRF26822 for ; Mon, 10 Mar 2003 14:42:27 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 14:39:01 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 14:39:01 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 14:39:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Mon, 10 Mar 2003 14:39:00 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLmPk7F2/xoJUSmS9eTiEzn79kC9wAwpbKw From: To: , Cc: , X-OriginalArrivalTime: 10 Mar 2003 12:39:00.0766 (UTC) FILETIME=[06ABABE0:01C2E702] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA10334 Hi, ... snip... > >>>What have I done wrong to this point? > >>> > >>> > >>> > >>He was illustrating what you are advocating, not looking in the INIT > >>and INIT-ACK.. if you do look in the INIT, then at you will > >>have populated the tie-tags since you would have recognized the > >>associations as being related (you would have found C in the the > >>INIT's list of addresses .. the one from D.. and then you would > >>have found the TCB that sent the INIT to C...) > >> > >> > > > >But the tie-tags are not to be populated in COOKIE-WAIT > states (according > >to RFC 2960 section 5.2.2) and in COOKIE-WAIT, COOKIE-ECHOED or > >SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New > text for Section > >5.2.2) > > > > > Hmm.. maybe they should be populated especially if you sent the > INIT-ACK back to the same place that you sent the INIT... I need > to think about this case... It could be the right thing to do... I think we should unify the responses... I.e., always sending the INIT ACK back to a "known" destination, and probably always populating the Tie Tags... Section 5.2 is going to be changed anyway... But the problem is that as it is now, you know it works... We should be very careful. I haven't thought about it, but probably populating the Tie Tags would change table 2 of the RFC as well... :-/ > >Now you are telling me they should be populated? If they > are populated > >and D is X (the attacker) then you will have surrendered the > VT of the > >existing TCB to the attacker. > > > > > No, you send the INIT-ACK back to the original place you sent > the INIT (as you just corrected me up above).. in such a case > if D were X you would be sending the INIT-ACK back to > C and you would not be giving anything away.. Exactly. > >So are you saying that I have done the wrong thing by > putting zero in the > >tie-tags? Then is RFC 2960 section 5.2.2 and IG 08 section > 2.6 new text > >for 5.2.2 in error? > > > > > No, but I begin to wonder if maybe we should not do it this way... aka > you send back the INIT-ACK to where you sent the orginal INIT > AND you populate the tie-tags when you are in COOKIE-WAIT state. > Since you would not be revealing anything to anyone else but who > you sent the INIT to anyway... let me think on this one for a while > but I am pretty sure that is why we did not send tie-tags in > COOKIE-WAIT > and if thats the case... with the new provisions of 2.6 IG it might be > ok... Let's think about it... > We might want to think about this for COOKIE_ECHOED as well... > Need to mull on this one for a bit.. > > > > >I would seriously like to know what I've done wrong up to this point. > > > >Your statements of what I have done wrong are not consistent > with either > >the RFC or the IG.... Please take a closer look at it and > tell me where > >I have gone astray. > > > No, I was not paying attention and was thinking of the > INIT-ACK case... As I already said, Brian implementation is wrong mostly because it creates a new IT when it shouldn't. Apart from that there is the problem of sending it to D instead of C. What matters it that at the end, Brian seems not to be able to establish an association... :-/ BR Iván Arias Rodríguez > R > > > > > >--brian > > > > > > > >>>(Note that I have not looked at the source address list in > the INIT.) > >>> > >>> > >>> > >>> > >>Yep and that is why your association will not come up when > it should.. > >> > >> > > > >But I have following the RFC and Section 2.6 to the letter > (except for > >the C/D thing which doesn't change the result here.) > > > >--brian > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > From owner-extdom.sctp-impl@sj-core-2.cisco.com Mon Mar 10 08:02:00 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10593 for ; Mon, 10 Mar 2003 08:01:57 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2ACudEY004703 for ; Mon, 10 Mar 2003 04:56:40 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2ACuds2002258 for ; Mon, 10 Mar 2003 04:56:39 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2ACuvof008306 for ; Mon, 10 Mar 2003 04:56:58 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2ACXkF19025 for ; Mon, 10 Mar 2003 14:33:46 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 14:30:20 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 14:30:19 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 14:30:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Mon, 10 Mar 2003 14:30:18 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLl7hWMfPWqItN/QmmqvgRDt1S9iwBESOvg From: To: , Cc: , X-OriginalArrivalTime: 10 Mar 2003 12:30:18.0983 (UTC) FILETIME=[CFA9E770:01C2E700] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA10593 Brian, Randall, > > >Populating tie-tags with zero is correct? (IG 2.6) > > > > > What tie-tags? so far I see a INIT being sent above.. > > In the INIT-ACK being formulated at this point... > > > > > > > > > > >Sending the INIT-ACK to C or D is moot (because it is sent to D > > >if the INIT arrived just before sending the INIT from A.) > > > > > > > > What does your statement have to do with anything.. you > > send a INIT to C (from A) and all of a sudden you get a > > INIT from D... you have NO idea that C and D are the same > > endpoint... so you MUST send back a INIT-ACK to D... > > Huh? Is the new text in section 2.6 for section 5.2.1 in error? > It tells me that in COOKIE-WAIT state I must send the INIT-ACK back > to the same address that the original INIT (sent by this endpoint) > was sent to. Brian, what are you trying to do? Should we ever answer to you again? Or even read your messages? Because I'm getting too tired of you playing with us... You know perfectly Randall was speaking about YOUR implementation, the one that sends the INIT ACK back to D, and the one that creates a new IT, BECAUSE YOU DON'T RECOGNIZE THE PEER SINCE YOU DON'T TAKE A LOOK TO THE ADDRESS PARAMETERS. YOUR implementation is the one that goes against the IG... YOURS. Whose behavior is the one explained above... And since we are showing you why YOUR implementation is not working in this case, that's why we say that you have to send the INIT ACK back to D, with a new IT, because YOU are not able to find the TCB without knowing what's inside the address parameters... Clear now? > Yet you tell me I MUST send it to D? I'm glad you don't have a > problem with me sending it to D (per RFC 2960) instead of to C > (per IG 08 2.6). It is not a question of agreeing with you or not, it is just a matter of fact that: > > INIT from D... you have NO idea that C and D are the same > > endpoint... so you MUST send back a INIT-ACK to D... But that only happen with YOUR implementation... ... snip... > > > > > >What have I done wrong to this point? > > > > > > > He was illustrating what you are advocating, not looking in the INIT > > and INIT-ACK.. if you do look in the INIT, then at you will > > have populated the tie-tags since you would have recognized the > > associations as being related (you would have found C in the the > > INIT's list of addresses .. the one from D.. and then you would > > have found the TCB that sent the INIT to C...) > > But the tie-tags are not to be populated in COOKIE-WAIT > states (according > to RFC 2960 section 5.2.2) and in COOKIE-WAIT, COOKIE-ECHOED or > SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New > text for Section > 5.2.2) This is right... Randall made a mistake here. However, the important thing is that with YOUR implementation you create a new IT, and send the INIT ACK back to D instead of C... That way you will establish an unique association as I shown in my previous mail... However, YOUR implementation is not able to do so in this case of INIT collision... > Now you are telling me they should be populated? If they are > populated > and D is X (the attacker) then you will have surrendered the VT of the > existing TCB to the attacker. See above... > So are you saying that I have done the wrong thing by putting > zero in the > tie-tags? Then is RFC 2960 section 5.2.2 and IG 08 section You know perfectly that YOUR implementation does a different thing (due to lack of information, since YOU don't look inside the address parameters), and at the end YOU are not able to establish the association... > 2.6 new text > for 5.2.2 in error? > > I would seriously like to know what I've done wrong up to this point. Read my previous mail as well if I haven't been clear enough... > Your statements of what I have done wrong are not consistent > with either > the RFC or the IG.... Please take a closer look at it and > tell me where > I have gone astray. I hope now it's easier to understand... > > > > > > > >(Note that I have not looked at the source address list in > the INIT.) > > > > > > > > > > Yep and that is why your association will not come up when > it should.. > > But I have following the RFC and Section 2.6 to the letter (except for > the C/D thing which doesn't change the result here.) You have not, Brian... You have created a new IT, and sent the INIT ACK back to D instead of C... BR Iván Arias Rodríguez > --brian > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > From owner-extdom.sctp-impl@sj-core-1.cisco.com Mon Mar 10 08:43:43 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18128 for ; Mon, 10 Mar 2003 08:43:42 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2ADP80E001773 for ; Mon, 10 Mar 2003 05:25:08 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2ADP7Sf023016 for ; Mon, 10 Mar 2003 05:25:07 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2ADPOof017447 for ; Mon, 10 Mar 2003 05:25:25 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2ADG8116394 for ; Mon, 10 Mar 2003 15:16:08 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 15:17:29 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 15:17:28 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 15:17:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Mon, 10 Mar 2003 15:17:27 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLmgRA8dIRJkyUVQ1qsTZHbsdLwEwAg1sYA From: To: , Cc: , X-OriginalArrivalTime: 10 Mar 2003 13:17:28.0246 (UTC) FILETIME=[66092D60:01C2E707] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA18128 Brian, > > Randall, > > Here's what I doing differently (but I still think that you owe > me and the OpenSS7 implementation an apology): > > When sending the INIT-ACK the implementation is choosing a new > verification tag instead of using the verification tag of the > existing TCB. But the implementation also follows the RFC in > that the INIT-ACK is sent back to the source of the INIT. If Yes, this is what the RFC says, but it has been changed by the IG. > the VT from the TCB was sent, it would be handed to the attacker > (in the initiate tag rather than tie-tags). The OpenSS7 > implementation sacrifices the collision case (rare) to protect > all other association initializations. Just because of this it is why section 5.2 has been modified... > The IG is not normative. This is why I asked on tsvwg why it > had not been advanced. There are many clauses in the IG that > are clarifications and interpretations of RFC 2960 and can be > implemented without the IG being normative, but 2.6 is not one > of them. RFC 2960 tells me that I MUST send the INIT-ACK back > to the source of the INIT. Since we detected this problem, that's why it was modified. > To follow 2.6 I need to find the existing TCB to use the VT from > the TCB in the initiate tag of the INIT-ACK and send the > INIT-ACK to C instead of D. But this still does not justify the > statement in 2.18, because it is only necessary to consider the > source address list in the INIT iff there exists one or more > TCBs for the port pair and local address, and iff one ore more > of those TCBs is in the COOKIE-WAIT state, (i.e. only if a > collision indeed can exist). It is certainly not necessary to > consider and arbitrarily long and suspect source address list on > all INITs, or even on INITs where there is no TCB for the port > pair and destination address, or even on INITs where there is no > TCB for the port pair and destination address in the COOKIE-WAIT > state. To consider an arbitrarily long and suspect source > address list on all INITs would open an implementation up to > DoS attacks with long source address lists. This is perfectly reasonable. You don't really need to take a look first to the address and then to the ports. You can do it as you like... You are right that if there isn't an open association whose source/destination ports match those of the INIT, not matter how deep you dig inside the address parameters, the INIT will never belong to any of the existing associations. But the text in section 2.18 doesn't say that you have to check the addresses anyway. It tells you that the addresses inside the parameters are as valid as the source address to identify the association. In other words, if you are checking the source address of the INIT (I guess that if you do that that's because either you check first the addresses -which I would say it is not the wiser thing to do-, or because you have already found a matching port pair), don't stop there and also use the addresses inside. > So I still think that the new paragraph D) in IG 2.18 is > unwarranted. It is OK to let implementations search how they > will as long as they meet the other requirements. I think there could be a change. So far we were thinking about something similar to: D) An INIT or INIT ACK chunk MUST be treated as belonging to an already established association (or one in the process of being established) if the use of any of the valid address parameters contained within the chunk would identify an existing TCB. > I will illustrate the need for the "extra" COOKIE-ECHO to limit > a DoS attack for the INIT-ACK case to address Caitlin's example > in a separate mail. > > I will also address in a separate mail the new text for section > 5.2.1 in section 2.6. There, I believe that it is unnecessary > for the receiver of an INIT to reject it just because it includes > new addresses when the packet source address of the INIT is one > of the existing addresses of the TCB. Also, that to not send an > INIT-ACK again opens a DoS attack (where the existing TCB in the > COOKIE-ECHOED state is for an association to a malicous endpoint). > > Please consider that--just maybe--I know what I'm talking about > (yes, I can right sometimes ;), and please skip the attacks and > innuendos on both myself and the OpenSS7 implementations. > > --brian Ok, so now finally agree that not checking the address parameters can make that the peer is not "able to establish associations in certain circumstances", as section 2.18.3 says. And now let's see about those problems/improvements... By the way. I perfectly know that you know what you are talking about. That's why I have completely read everything you have written in your mails... It is just the way you talk sometimes what I don't like... :-/ BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-core-5.cisco.com Mon Mar 10 08:47:03 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18785 for ; Mon, 10 Mar 2003 08:46:57 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2ADRFhs001465; Mon, 10 Mar 2003 05:27:15 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEH35997; Mon, 10 Mar 2003 05:27:13 -0800 (PST) Message-ID: <3E6C92B1.2070607@cisco.com> Date: Mon, 10 Mar 2003 07:27:13 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Caitlin Bestler , sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030303103316.B15597@openss7.org> <20030308025453.A26345@openss7.org> <3E69DE4D.8010609@cisco.com> <20030309153850.B25482@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Sat, 08 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian: >> >>One key thing I don't think I understand in your scenario below... something >>Steve Bellovin once commented upon to me.. >> >>Why are you establishing an association to a malicious host? >> >>Its one thing when you are a passiver server... but it is quite >>another when YOU choose to make this establishement to >>a malicious host... >> >>I would classify this as way beyond a corner case ... >> >>Its quite likely to have a collision case.. where both attempt >>to contact at the same time.. but you making the >>connections by your choice to a good host and a malicious >>host seem a bit over the top... >> >> > >Malicious web servers exist in the wild. Two points: > >1) For a general purpose protocol, one should not make > assumptions about the probability of certain events, because > to do so makes assumptions about the application. (I think > it was You, Ivan or Caitlin that told me this.) > > I can tell you that for any current IETF applications, > Caitlin's example will not occur (because it relies upon > static port allocation on both peers and misconfiguration > (SO_REUSEADDR) on the peer launching multiple INITs). > > In 1999 Motorola had a display at telcom Geneva in that display a prototype of RSERPOOL was in use. None of the servers used SO_REUSEADDR and NONE of the servers used fixed ports. You are assuming that SO_REUSE is being used to gain access to the port again.. and this is just not the case. As I stated before it IS possible to listen and connect (We were doing this with TCP as well).. There is no mis-configuration and no mis-use.. but instead peer-2-peer networking.. > You and Ivan tell me on one hand that saying that the > situation will not occur or will occur with only extremely > low probabiliy is not good enough, and that sending an > "extra" packet in this low probability situation is also not > good enough, but now you say that it is good enough to have > a vulnerability because it is low probability? > > I think, quite the reverse, that a corner case with a > vulnerability deserves far more attention than a corner case > with what seems on the surface to be an "extra" packet. > Attached is an analysis of why sending the "extra" > COOKIE-ECHO actually limits the attack but does not solve > it. > > To solve it requires that Host A has prior knowledge of the > addresses belonging to the endpoint to which it launches the > INIT. > No I disagree... the security issue you talk about has a fix that does NOT involve prior knowledge of all addresses.,.. > >2) It is naive when considering security to assume that just > because you are launching an INIT to an endpoint that it can > be trusted, especially on the Internet. Do you want your > transport protocol to place trust in every web server that > you browse? I think not. > >So I don't think that it is over the top at all. > > If an application is concerned in this manner there is another way that I have mentioned previously... and it does not involve pre-programming the peers addresses.. > > > >>If you want to look at this case.. what about >> >>----------INIT from A:1000 to X:1000--------------------> >><---------INIT-ACK from X:1000 to A:1000 (IP-X,IP-B)--- >>> paint below, you can't establish to Host B in fact >> the app THINK's it is already talking to B >> once the rest of the association comes up> >> >> > >Precisely. Address X has been verified to some level of >confidence. X actually returned the proper VT to the proper, >destination address with the proper port pair. But the source >address list has not been verified. If action is taken on the >source address list that affects whether those addresses will be >accepted from the legitimate hosts that own them, then the >protocol is naive and vulnerable to attack. See below for a >detailed attack. > > > >>I can't see how you would be concerned about the >>case below and not care about the same scenario >>with just a bit of different message ordering... >> >> > >Actually I am concerned about both message orderings of the >INIT. See the example below where the message ordering is as >you show above. > > > >>So I don't see the merit in your argument and I think Caitlin's >>comments on extra network traffic are still not addressed by your >>comments below... especially since you are arguing from an extreme >>corner case... >> >> > >See the more detailed argument below as to how the "extra" >COOKIE-ECHO limits the vulnerability, but does not solve it. >Solving the vulnerability requires that A know the addresses of >multi-homed hosts to which it launches an init. > Nope > (This is not >too unrealistic: DNS can return multiple IP addresses for a >given host name, and DNS is the normal way that an application >discovers IP addresses to send the INIT in the first place.) > > DNS is a very static thing.. and is much harder to get updated then you allude to here.. besides its NOT needed >Here's the argument: > > >Host A/B Host X Host C/D > | | | > |INIT A:1000 -> X:1000 | | > |---------------------------------------------->| | > |TCB1: | | > |VT: X | | > |PT: 0 | | > |Loc: A:1000 | | > |Rem: X:1000 | | > |State: COOKIE-WAIT | | > | | | > |INIT A:1000 -> C:1000 | | > |------------------------------------------------------->| > |TCB2: | | > |VT: Y | | > |PT: 0 | | > |Loc: A:1000 | | > |Rem: C:1000 | | > |State: COOKIE-WAIT | | > | | | > | INIT-ACK X:1000 -> A:1000 (D)| | > |<----------------------------------------------| | > |(TCB2 cannot be found on source addr list) | | > |(TCB1 is found) | | > | | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > |TCB1: | | > |VT: X | | > |PT: W | | > |Loc: A:1000 | | > |Rem: X:1000, D:1000 | | > |State: COOKIE-ECHOED | | > | X does not | | > | send (or delays) | > | COOKIE-ACK | | > | | | > | INIT-ACK C:1000 -> A:1000 (D)| > |<-------------------------------------------------------| > | | | > >Did you expect Host A to not send the COOKIE-ECHO for TCB2 and >error the connection attempt to the user of TCB2? The user of >TCB2 will retry, resulting in: > Our implementation would recognize, when processing the INIT-ACK of TCB2 (from C) and abort the association setup.. so there would be no timer firing.. the user would get an error... This is the same as if our association to X had gone out and X had included C's address.. aka camping on someone elses address. > > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > I dont understand how would you get a cookie-timeout on TCB2? I could see a TCB2 t1-timeout.. but TCB2 has never seen the INIT-ACK at this point. TCB1 holds X and D now (if I am following your case correctly) and so when the arriving INIT-ACK from 'C' comes in you would find TCB1... not 2.. so TCB2 is still in COOKIE-WAIT (not COOKIE-ECHOED).. in our implementation (as I noted above) it would be aborted... so the app would know something is up... >Note that X can keep the T1-cookie timeout initially high by >delaying the response to the INIT by RTO.Initial. T1-cookies >double with each retransmission up to 60 seconds, so the >sequence is 3sec, 6sec, 12sec, 24sec, 48sec, 60sec, 60sec, 60sec >which is 273 seconds or about 4 minutes. This can be extended >another 30 seconds by responding with a COOKIE-ACK just before >the final timeout (or just before the application times out) >and keeping the association established until after 30 more >seconds a HEARTBEAT is sent to D which will illicit an abort and >then go around again. > A couple of questions on this scenario in general... A) Why is A contacting X AND C at the same time? Most likely to gain some sort of service.. If so how is X going to know to include D, or have any idea that C is being contacted? I would think this is huge guess on the part of X and the probabilities of getting this right would be somewhere in the order of guessing a Vtag that is not dilluded 1 in 4 Billion.. Have to ask M Tuexen if he could work up the probabilities :> B) You of course are assuming that X would pre-know the values that are placed on RTO.Initial and max-retran... which of course are user settable... granted using the defaults would be a good guess but they may not be correct... C) What does X have to gain from this attack? Does it fool A into thinking it is talking to C, I don't think so.. especially since this app purposely contacted X... it had a reason to do so and is expecting some service/reply from X. If X wants to deny converstations with 'C' .. then this only works if you just so happen to begin to talk to X and C at the same time. And if its just a plain ole DOS attack it seems rather a foolish one... since up front generation of lots of INIT's would be a far better choice... Basically I just can't see what X is trying to gain in this scenario.. this is in the catagory of what is the threat? and what is the results? The result is that for some minutes you cannot contact one particular host if you happen to contact two hosts at about the same time for service and one of the hosts just so happens to guess/know you are contacting the other one at the same time.. seems like very very fine thread.. and a very minimum threat to me. But lets continue anyway... > If the attacker does not SACK any >received data then Host A may heartbeat X before D, or X could >add several of bogus addresses into the list that will be >heartbeated before D. > Why would it do that... A INIT/INIT-ACK counts as a RTT updating thing as well as a COOKIE/COOKIE-ACK.. so in that sense D is always the first one that A should HB.. > Since T3-rtx is held at 60 seconds, X can >get an average of 2 minutes out of each bogus destination in the >source address list. > Why do you say for each? Once the association is up, the first bogus destination you HB will return an ABORT and knock the whole thing down. If X never sends anything to A then X will not even know when the association collapses... A will get the ABORT from the first bogus address, kill the assocation.. so then if C is re-attempted you end up with that association coming up... > The application may timeout before that >but the timeouts of Internet applications are well known. > > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > | | | > |INIT A:1000 -> C:1000 | | > |------------------------------------------------------->| > |TCB2: | | > |VT: Y | | > |PT: 0 | | > |Loc: A:1000 | | > |Rem: C:1000 | | > |State: COOKIE-WAIT | | > | INIT-ACK C:1000 -> A:1000 (D)| > |<-------------------------------------------------------| > >Refused, because TCB exists for A:1000<-->D:1000? > If the COOKIE-ACK has not yet been returned the association (as you have pointed out) is not fully formed. As such I would think another approach one could take in examining the INIT-ACK address list is find both sets of TCB's and thus put both of them into question.... we don't do this but one could quite easily.. At the point we find the other assocaition and abort your "TCB2" it would be a simple step to check its state.. if it is not fully formed one could: 1) Abort both. 2) Abort one (this is currently what we do). 3) Look at the state of the existing one, if still forming let the cookie-echo go out, but instead mark each as suspect and needing HB before letting either proceed to ESTABLISHED... if you will put a delayed for security reasons... kind of like going to an airport but not randomly being singled out .. instead being singled out due to a problem. Then when the COOKIE-ACK arrives back from each you can HB each address before proceeding and thus find out who is who ... > > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > | . | | > | . repeat | | > | . | | > >Note that X can find the address to include in its INIT merely >by sending an INIT to C or D and getting an INIT-ACK. > > > And then guessing who is going to contact me at the same exact time that it is contacting C or D... >If the INIT-ACK is not refused, and a COOKIE-ECHO is returned >(the "extra" packet), the following occurs: > > >Host A/B Host X Host C/D > | | | > |INIT A:1000->X:1000 | | > |---------------------------------------------->| | > |TCB1: | | > |VT: X | | > |PT: 0 | | > |Loc: A:1000 | | > |Rem: X:1000 | | > |State: COOKIE-WAIT | | > | | | > |INIT A:1000->C:1000 | | > |------------------------------------------------------->| > |TCB2: | | > |VT: Y | | > |PT: 0 | | > |Loc: A:1000 | | > |Rem: C:1000 | | > |State: COOKIE-WAIT | | > | | | > | INIT-ACK X:1000->A:1000 (D)| | > |<----------------------------------------------| | > |(TCB2 cannot be found on source addr list) | | > |(TCB1 is found) | | > | | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > |TCB1: X does not | | > |VT: X send (or delays) | > |PT: W COOKIE-ACK | | > |Loc: A:1000 | | > |Rem: X:1000, D:1000 | | > |State: COOKIE-ECHOED | | > | INIT-ACK C:1000->A:1000 (D)| > |<-------------------------------------------------------| > | | | > |COOKIE-ECHO A:1000->C:1000 | | > |------------------------------------------------------->| > |TCB2: | | > |VT: X | | > |PT: Z | | > |Loc: A:1000 | | > |Rem: C:1000, D:1000 | | > |State: COOKIE-ECHOED | | > | COOKIE-ACK C:1000->A:1000| > |<-------------------------------------------------------| > |TCB2: | | > |VT: X | | > |PT: Z | | > |Loc: A:1000 | | > |Rem: C:1000, D:1000 | | > |State: ESTABLISHED | | > | | | > |(Discard TCB1, inform user) (attacker thwarted)| | > | | | > >What this would do is force attacker X to reply quickly with >a COOKIE-ACK in order to block the legitimate host as in: > But how do you still know which is the hacker and which is the legit server is it X/D or C/D? In this case you are saying its whoever gets a COOKIE-ACK to me first... this is not good.. since you can't tie the two associations (by your refusal to look in the INIT/INIT-ACK) you can't do anything but hope that the real user is faster or closer... Instead one can do as I state above in <3> hmm I think I will look into getting this coded into the BSD implementation seems like a good general solution to the issue... > >Host A/B Host X Host C/D > | | | > |INIT A:1000->X:1000 | | > |---------------------------------------------->| | > |TCB1: | | > |VT: X | | > |PT: 0 | | > |Loc: A:1000 | | > |Rem: X:1000 | | > |State: COOKIE-WAIT | | > | | | > |INIT A:1000->C:1000 | | > |------------------------------------------------------->| > |TCB2: | | > |VT: Y | | > |PT: 0 | | > |Loc: A:1000 | | > |Rem: C:1000 | | > |State: COOKIE-WAIT | | > | | | > | INIT-ACK X:1000->A:1000 (D)| | > |<----------------------------------------------| | > |(TCB2 cannot be found on source addr list) | | > |(TCB1 is found) | | > | | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > |TCB1: | | > |VT: X | | > |PT: W | | > |Loc: A:1000 | | > |Rem: X:1000, D:1000 | | > |State: COOKIE-ECHOED | | > | INIT-ACK C:1000->A:1000 (D)| > |<-------------------------------------------------------| > | | | > | COOKIE-ACK X:1000->A:1000| | > |<----------------------------------------------| | > |TCB1: | | > |VT: X | | > |PT: W | | > |Loc: A:1000 | | > |Rem: X:1000, D:1000 | | > |State: ESTABLISHED | | > | | | > |(Discard TCB2, inform user) | | > | | | > >What this serves to do is put the attacker immediately into the >ESTABLISHED state. If the attacker delays the COOKIE-ACK, the >the legitimate peer will win the race and the attack is >thwarted. The attacker cannot block for the initial 4 minutes, >but can still place bogus addresses in the address list that >will extend the period of time before a HEARTBEAT/ABORT sequence >to D takes the association down. > And <3> above will avoid even this... > >The major difference is that, in the ESTABLISHED state, the >user of TCB1 can challenge the peer. In the COOKIE-ECHOED >state, the user of TCB1 is blocked from communicating on the >association and the ULP cannot assist in detecting the attack. > >Because X and D are indistinguishable to "A" ("A" has no prior >knowledge of D or X), the only way to limit the attack is by >sending the "extra" COOKIE-ECHO. So for the sake of security in >this case, whether it be rare or not, it is better to send the >extra COOKIE-ECHO than not. > Yes I see the point of the "extra" COOKIE-ECHO... in this one corner case where you have non-completely overlapping INIT-ACK's aka one is saying (X/D) the other (C/D).. Caitlins example was one where you had the same overlap.. (C/D) and (C/D) in the INIT's.. using <3> , one could easily tell if the two INIT-ACK's were completely overlapping or partially overlapping ... this way the legitimate case would NOT generate the extra COOKIE-ECHO and the "evil server" case would so that one could proceed carefully and select the correct address set for the peer... I.e. which is the evil attacker X/D or C/D.... This is a interesting case and I do think I will put it on my discussion list with Steve... if I can get some of his time... I am not sure if it warrents writting the code to handle it.. I will ask him before I get to deep into coding <3> :-0 > >Taking actions on unverifiable addresses in the source address >list of INIT-ACKs is IMO quite naive. It opens the protocol up >to an entire spectrum of addresss spoofing attacks. The only >source address that is verified in INIT and INIT-ACK are the >packet header source addresses. (The INIT packet source addres >is verified by HMAC on COOKIE-ECHO; the INIT-ACK source address >is verified by port pair, destination address and VT of the >INIT-ACK matching those of the INIT.) > >The reason that 2.6 in the COOKIE-WAIT state works for collision >is because the INIT-ACK with the existing VT is sent to the same >address as the INIT. The receiver of the INIT already has the >VT from the INIT so sending it in the INIT-ACK to same address >does not expose the VT. > >In ths case, it is not possible for "A" to determine whether D >truly belongs to X or whether it truly belongs to C without >prior knowledge of address D. In the case where knowledge of >address D can be easily obtained (e.g. DNS query), "A" is even >the more vulnerable to X if it does not utilize the same >readily available information about D. > >This is really scary. Server X can easily discover the secondary >addresses service to which it wishes to block access by launching >INITs to them and getting INIT-ACKs. Then server X can place >_all_ the secondardy addresses in the address list (say 200 of >them). > I have so far, not stumbled upon any such web servers.. aka that are hackers that try to block other sites from being hit... Steve may know a bit more.. I don't as yet believe this is that scary of a problem... And if it is, the steps in <3> above can be used to correct it.. I think a far more likely DOS attack would be when X gets a INIT from A it then starts sending ton's of INIT's to A until it finds a open port.. then it can generate lots and lots and lots of INIT's from bogus addresses that nicely get you to do the HMAC algorithms.. I would be much more concerned about that aspect than this one .. but like I said Steve may have a different perspective.... if so I will code up <3> for our implementation... > >The one way that I can see to block the attack is by not >permitting sockets bound to a static port address with >SO_REUSEADDR to have their TCBs expanded by the INIT-ACK beyond >the addresses that were supplied to connect() iff any other TCB >is bound to the same static address (i.e., if resuse is actually >in effect, for our imp that means if the bind bucket is not >marked for fastreuse). Then the attack cannot form, and neither >association will form unless sufficient prior knowledge was >supplied to at least one of the two connect()s. This is >certainly not too strong a restriction to place on socket users. > > I see no reason for this restriction.. >This also means that the "extra" COOKIE-ECHO would never occur >because the INIT-ACK can be refused on the basis of the bind >characteristics. > >I still don't need to examine the address list when searching >for a matching TCB, because any action taken on the address list >is vulnerable to attack. The address list has not been >verified. > >The only use for the packet source address in the INIT is to >know where to send (in the collision corner case) the INIT-ACK, >and to populate the cookie. > > Far more likely of a corner case than your evil attacker server (sort of passive agressive actually :>).... >The only use for the packet source address and source address >list in the INIT-ACK is to expand unexpanded TCBs. (In this >case, if sufficient address information is not supplied I will >refuse to expand the TCB.) > >I hope this illustrates why it is unecessary (and is a secuirty >risk) to examine the source address list of INIT-ACK. > > Nope, I don't see it.. sorry Brian there are other ways to deal with this. In fact I think your weakening of the V-Tag's security is a far far far greater risk then the scenario you paint above... and even your scenario can be easily dealt with.. it will require code.. but it can be dealt with.. A simple 'un-trusted' flag could be added to the socket-api to allow one to declare.. I don't trust this peer HB every address before we converse.. Not counting the corner case you illustrate above which I laid out a solution that will immediately bring the bogus peer into suspect even without a 'un-trusted' flag. One other thing I want to note... before I read your 2.6 issues.. 5.2.1 of RFC2960 states: "5.2.1 INIT received in COOKIE-WAIT or COOKIE-ECHOED State (Item B) This usually indicates an initialization collision, i.e., each endpoint is attempting, at about the same time, to establish an association with the other endpoint. Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an endpoint MUST respond with an INIT ACK using the same parameters it Stewart, et al. Standards Track [Page 60] RFC 2960 Stream Control Transmission Protocol October 2000 sent in its original INIT chunk (including its Initiation Tag, unchanged). These original parameters are combined with those from the newly received INIT chunk. The endpoint shall also generate a State Cookie with the INIT ACK. The endpoint uses the parameters sent in its INIT to calculate the State Cookie. " Note the 'MUST respond with an INIT ACK using the same parameters it sent in it soriginal INIT chunk (including its Initiation Tag," Your implementation, at least from your conversations in this thread, does NOT do this... (in the double multi-homed case aka the colliding INIT's that Ivan painted) R >I will talk to the "new addresses" of section 2.6 in a separate >mail. (This one is already way too long ;) > >--brian > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-2.cisco.com Mon Mar 10 08:48:26 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19082 for ; Mon, 10 Mar 2003 08:48:22 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2ADLoEY019434 for ; Mon, 10 Mar 2003 05:21:50 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2ADL71S000373 for ; Mon, 10 Mar 2003 05:21:08 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h2ADJn2W029613 for ; Mon, 10 Mar 2003 05:19:50 -0800 (PST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2ACsZ124383 for ; Mon, 10 Mar 2003 14:54:35 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 14:55:55 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 14:55:54 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 14:55:54 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 14:55:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Mon, 10 Mar 2003 14:55:53 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLmQGh8oGfnCMqET/OUdam984+alAAwa9sg From: To: , Cc: , X-OriginalArrivalTime: 10 Mar 2003 12:55:54.0099 (UTC) FILETIME=[62AA0430:01C2E704] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA19082 Randall, ... snip... > >But the tie-tags are not to be populated in COOKIE-WAIT > states (according > >to RFC 2960 section 5.2.2) and in COOKIE-WAIT, COOKIE-ECHOED or > >SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New > text for Section > >5.2.2) > > > >Now you are telling me they should be populated? If they > are populated > >and D is X (the attacker) then you will have surrendered the > VT of the > >existing TCB to the attacker. > > > >So are you saying that I have done the wrong thing by > putting zero in the > >tie-tags? Then is RFC 2960 section 5.2.2 and IG 08 section > 2.6 new text > >for 5.2.2 in error? > > > >I would seriously like to know what I've done wrong up to this point. > > > >Your statements of what I have done wrong are not consistent > with either > >the RFC or the IG.... Please take a closer look at it and > tell me where > >I have gone astray. > > > > After thinking on this a bit more and re-reading the IG and > the original > RFC... > I think the following changes are in order: > > 1) For the IG 2.6, as I said earlier, we need to change the > wording in the > IG to not send the "adding new address" error cause in the ABORT > sent. This > way, as Brian points out, we will not be revealing info to the > attacker.. > we may want to take Ivan's approach where we send the > INIT-ACK back > to one of the existing addresses... the down side of this is as > Brian pointed > out, by not getting information back, if it is an attacker, the > attacker can > deduce that an association exists.. (I will ask Steve on > this point > as well)... But the association cannot be established anyway... The difference between not answering the INIT and not answering the COOKIE ECHO, is that you may have more reasons to drop the COOKIE ECHO... However, I think that in most of them you will have to send an ABORT back to the sender... :-/ If you are an attacker and you include somebody's addresses in your INIT, and then you try to establish the association, if you haven't done any other wrong thing, you will know that if you weren't able to establish the association and you didn't get any answer, most probably that's because some of the addresses were already used by another association. And, I haven't thought about this, but, what would happen if the address list in the INIT contains addresses of *more than one* other association? This would clearly identify the INIT as coming from an attacker... :-/ > 2) For the same section in the IG we need to populate the > tie-tags in the > COOKIE-WAIT state as well, not just the COOKIE-ECHOED state as > is currently in RFC2960. With the current changes in the > IG (as Brian > pointed out... you send back to the place you sent the > INIT to) there > is no danger of revealing your VT to a mallicious hacker > in this case... Changing this means that we need to send the INIT ACK back to a "known" address... BR Iván Arias Rodríguez > 3) We may need a requirement that you MUST validate addresses and not > solely depend on the uniquness of the V-Tags... otherwise > you weaken > security... I will discuss this one with Steve Bellovin > in S.F. and see > what he has to say... > > R From owner-extdom.sctp-impl@sj-core-1.cisco.com Mon Mar 10 08:53:36 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20075 for ; Mon, 10 Mar 2003 08:53:32 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2ADej0E011358; Mon, 10 Mar 2003 05:40:45 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEH36733; Mon, 10 Mar 2003 05:40:44 -0800 (PST) Message-ID: <3E6C95DC.6090801@cisco.com> Date: Mon, 10 Mar 2003 07:40:44 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: bidulock@openss7.org, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez@nokia.com wrote: > Randall, > > ... snip... > > > >>>But the tie-tags are not to be populated in COOKIE-WAIT >>> >>> >>states (according >> >> >>>to RFC 2960 section 5.2.2) and in COOKIE-WAIT, COOKIE-ECHOED or >>>SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New >>> >>> >>text for Section >> >> >>>5.2.2) >>> >>>Now you are telling me they should be populated? If they >>> >>> >>are populated >> >> >>>and D is X (the attacker) then you will have surrendered the >>> >>> >>VT of the >> >> >>>existing TCB to the attacker. >>> >>>So are you saying that I have done the wrong thing by >>> >>> >>putting zero in the >> >> >>>tie-tags? Then is RFC 2960 section 5.2.2 and IG 08 section >>> >>> >>2.6 new text >> >> >>>for 5.2.2 in error? >>> >>>I would seriously like to know what I've done wrong up to this point. >>> >>>Your statements of what I have done wrong are not consistent >>> >>> >>with either >> >> >>>the RFC or the IG.... Please take a closer look at it and >>> >>> >>tell me where >> >> >>>I have gone astray. >>> >>> >>> >>After thinking on this a bit more and re-reading the IG and >>the original >>RFC... >>I think the following changes are in order: >> >>1) For the IG 2.6, as I said earlier, we need to change the >>wording in the >> IG to not send the "adding new address" error cause in the ABORT >>sent. This >> way, as Brian points out, we will not be revealing info to the >>attacker.. >> we may want to take Ivan's approach where we send the >>INIT-ACK back >> to one of the existing addresses... the down side of this is as >>Brian pointed >> out, by not getting information back, if it is an attacker, the >>attacker can >> deduce that an association exists.. (I will ask Steve on >>this point >>as well)... >> >> > > But the association cannot be established anyway... The difference between not answering the INIT and not answering the COOKIE ECHO, is that you may have more reasons to drop the COOKIE ECHO... However, I think that in most of them you will have to send an ABORT back to the sender... :-/ > > If you are an attacker and you include somebody's addresses in your INIT, and then you try to establish the association, if you haven't done any other wrong thing, you will know that if you weren't able to establish the association and you didn't get any answer, most probably that's because some of the addresses were already used by another association. > > Yeah, I do think an ABORT must go back to the sender of the C-E .. but maybe with no error causes... > And, I haven't thought about this, but, what would happen if the address list in the INIT contains addresses of *more than one* other association? This would clearly identify the INIT as coming from an attacker... :-/ > > Yes, this is a good point.. one could use this type of information to determine an attacker and I would expect log this somewhere a counter or something.... but one must be careful about logging since this to can be an attack :-0 > > >>2) For the same section in the IG we need to populate the >>tie-tags in the >> COOKIE-WAIT state as well, not just the COOKIE-ECHOED state as >> is currently in RFC2960. With the current changes in the >>IG (as Brian >> pointed out... you send back to the place you sent the >>INIT to) there >> is no danger of revealing your VT to a mallicious hacker >>in this case... >> >> > > Changing this means that we need to send the INIT ACK back to a "known" address... > > The more I think on it, we really don't need the tie-tags in the COOKIE-WAIT state, as you point out the key is to get the same tag so you can bring up the association and of course follow 2.6 of the IG.. I think we should leave this alone... and if a implementation wants to populate the tie-tags.. thats ok too... it servers really no purpose (outside of making the code consistent)... R > BR Iván Arias Rodríguez > > > >>3) We may need a requirement that you MUST validate addresses and not >> solely depend on the uniquness of the V-Tags... otherwise >>you weaken >> security... I will discuss this one with Steve Bellovin >>in S.F. and see >> what he has to say... >> >>R >> >> > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Mon Mar 10 08:53:45 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20124 for ; Mon, 10 Mar 2003 08:53:44 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2ADZ2hs006476; Mon, 10 Mar 2003 05:35:03 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEH36473; Mon, 10 Mar 2003 05:35:01 -0800 (PST) Message-ID: <3E6C9485.4010605@cisco.com> Date: Mon, 10 Mar 2003 07:35:01 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: bidulock@openss7.org, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Ivan: a few comments... Ivan.Arias-Rodriguez@nokia.com wrote: > Hi, > > ... snip... > > > >>>>>What have I done wrong to this point? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>He was illustrating what you are advocating, not looking in the INIT >>>>and INIT-ACK.. if you do look in the INIT, then at you will >>>>have populated the tie-tags since you would have recognized the >>>>associations as being related (you would have found C in the the >>>>INIT's list of addresses .. the one from D.. and then you would >>>>have found the TCB that sent the INIT to C...) >>>> >>>> >>>> >>>> >>>But the tie-tags are not to be populated in COOKIE-WAIT >>> >>> >>states (according >> >> >>>to RFC 2960 section 5.2.2) and in COOKIE-WAIT, COOKIE-ECHOED or >>>SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New >>> >>> >>text for Section >> >> >>>5.2.2) >>> >>> >>> >>> >>Hmm.. maybe they should be populated especially if you sent the >>INIT-ACK back to the same place that you sent the INIT... I need >>to think about this case... >> >> > > It could be the right thing to do... > > I think we should unify the responses... I.e., always sending the INIT ACK back to a "known" destination, and probably always populating the Tie Tags... > > Section 5.2 is going to be changed anyway... But the problem is that as it is now, you know it works... We should be very careful. > > I haven't thought about it, but probably populating the Tie Tags would change table 2 of the RFC as well... :-/ > > I have thought about it even more.. and I think the bottom line is it works either way.. The tie-tags are un-important and in fact by there not being populated you end up at that third row in the 2960 table... If they do get populated it does not change the outcome at all.. since the Tag matches... So leaving things alone is probably best.. but I don't think it really matters if you populate the tie-tags or not... There no restriction NOT to and I think there is no mandate to populate them.. this is ok... > > >>>Now you are telling me they should be populated? If they >>> >>> >>are populated >> >> >>>and D is X (the attacker) then you will have surrendered the >>> >>> >>VT of the >> >> >>>existing TCB to the attacker. >>> >>> >>> >>> >>No, you send the INIT-ACK back to the original place you sent >>the INIT (as you just corrected me up above).. in such a case >>if D were X you would be sending the INIT-ACK back to >>C and you would not be giving anything away.. >> >> > > Exactly. > > > >>>So are you saying that I have done the wrong thing by >>> >>> >>putting zero in the >> >> >>>tie-tags? Then is RFC 2960 section 5.2.2 and IG 08 section >>> >>> >>2.6 new text >> >> >>>for 5.2.2 in error? >>> >>> >>> >>> >>No, but I begin to wonder if maybe we should not do it this way... aka >>you send back the INIT-ACK to where you sent the orginal INIT >>AND you populate the tie-tags when you are in COOKIE-WAIT state. >>Since you would not be revealing anything to anyone else but who >>you sent the INIT to anyway... let me think on this one for a while >>but I am pretty sure that is why we did not send tie-tags in >>COOKIE-WAIT >>and if thats the case... with the new provisions of 2.6 IG it might be >>ok... >> >> > > Let's think about it... > > Probably it is not needed... you can do it but it does not matter if you do or don't.. since there is no harm either way leaving it unspecified is probably best... > > >>We might want to think about this for COOKIE_ECHOED as well... >>Need to mull on this one for a bit.. >> >> >> >> >> >>>I would seriously like to know what I've done wrong up to this point. >>> >>>Your statements of what I have done wrong are not consistent >>> >>> >>with either >> >> >>>the RFC or the IG.... Please take a closer look at it and >>> >>> >>tell me where >> >> >>>I have gone astray. >>> >>> >>> >>No, I was not paying attention and was thinking of the >>INIT-ACK case... >> >> > > As I already said, Brian implementation is wrong mostly because it creates a new IT when it shouldn't. Apart from that there is the problem of sending it to D instead of C. > > What matters it that at the end, Brian seems not to be able to establish an association... :-/ > > exactly.. > BR Iván Arias Rodríguez > > > >>R >> >> >> >> >>>--brian >>> >>> >>> >>> >>> >>>>>(Note that I have not looked at the source address list in >>>>> >>>>> >>the INIT.) >> >> >>>>> >>>>> >>>>> >>>>> >>>>Yep and that is why your association will not come up when >>>> >>>> >>it should.. >> >> >>>> >>>> >>>> >>>> >>>But I have following the RFC and Section 2.6 to the letter >>> >>> >>(except for >> >> >>>the C/D thing which doesn't change the result here.) >>> >>>--brian >>> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> >> > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Mon Mar 10 08:54:43 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20305 for ; Mon, 10 Mar 2003 08:54:42 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2ADjQhs012870; Mon, 10 Mar 2003 05:45:27 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEH36902; Mon, 10 Mar 2003 05:45:25 -0800 (PST) Message-ID: <3E6C96F4.6030003@cisco.com> Date: Mon, 10 Mar 2003 07:45:24 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: bidulock@openss7.org, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi again Ivan :> Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > > >>Randall, >> >>Here's what I doing differently (but I still think that you owe >>me and the OpenSS7 implementation an apology): >> >>When sending the INIT-ACK the implementation is choosing a new >>verification tag instead of using the verification tag of the >>existing TCB. But the implementation also follows the RFC in >>that the INIT-ACK is sent back to the source of the INIT. If >> >> > > Yes, this is what the RFC says, but it has been changed by the IG. > > > >>the VT from the TCB was sent, it would be handed to the attacker >>(in the initiate tag rather than tie-tags). The OpenSS7 >>implementation sacrifices the collision case (rare) to protect >>all other association initializations. >> >> > > Just because of this it is why section 5.2 has been modified... > > > >>The IG is not normative. This is why I asked on tsvwg why it >>had not been advanced. There are many clauses in the IG that >>are clarifications and interpretations of RFC 2960 and can be >>implemented without the IG being normative, but 2.6 is not one >>of them. RFC 2960 tells me that I MUST send the INIT-ACK back >>to the source of the INIT. >> >> > > Since we detected this problem, that's why it was modified. > > Exactly.. and eventually when we close out the IG it will become the replacement text for the current text in RFC2960... :> > > >>To follow 2.6 I need to find the existing TCB to use the VT from >>the TCB in the initiate tag of the INIT-ACK and send the >>INIT-ACK to C instead of D. But this still does not justify the >>statement in 2.18, because it is only necessary to consider the >>source address list in the INIT iff there exists one or more >>TCBs for the port pair and local address, and iff one ore more >>of those TCBs is in the COOKIE-WAIT state, (i.e. only if a >>collision indeed can exist). It is certainly not necessary to >>consider and arbitrarily long and suspect source address list on >>all INITs, or even on INITs where there is no TCB for the port >>pair and destination address, or even on INITs where there is no >>TCB for the port pair and destination address in the COOKIE-WAIT >>state. To consider an arbitrarily long and suspect source >>address list on all INITs would open an implementation up to >>DoS attacks with long source address lists. >> >> > > This is perfectly reasonable. You don't really need to take a look first to the address and then to the ports. You can do it as you like... > > You are right that if there isn't an open association whose source/destination ports match those of the INIT, not matter how deep you dig inside the address parameters, the INIT will never belong to any of the existing associations. > > But the text in section 2.18 doesn't say that you have to check the addresses anyway. It tells you that the addresses inside the parameters are as valid as the source address to identify the association. In other words, if you are checking the source address of the INIT (I guess that if you do that that's because either you check first the addresses -which I would say it is not the wiser thing to do-, or because you have already found a matching port pair), don't stop there and also use the addresses inside. > > > >>So I still think that the new paragraph D) in IG 2.18 is >>unwarranted. It is OK to let implementations search how they >>will as long as they meet the other requirements. >> >> > > I think there could be a change. So far we were thinking about something similar to: > > D) An INIT or INIT ACK chunk MUST be treated as belonging > to an already established association (or one in the > process of being established) if the use of any of the > valid address parameters contained within the chunk > would identify an existing TCB. > > > This, I think is a very nice wording.. it says the same thing but a bit more specific :> > > >>I will illustrate the need for the "extra" COOKIE-ECHO to limit >>a DoS attack for the INIT-ACK case to address Caitlin's example >>in a separate mail. >> >>I will also address in a separate mail the new text for section >>5.2.1 in section 2.6. There, I believe that it is unnecessary >>for the receiver of an INIT to reject it just because it includes >>new addresses when the packet source address of the INIT is one >>of the existing addresses of the TCB. Also, that to not send an >>INIT-ACK again opens a DoS attack (where the existing TCB in the >>COOKIE-ECHOED state is for an association to a malicous endpoint). >> >>Please consider that--just maybe--I know what I'm talking about >>(yes, I can right sometimes ;), and please skip the attacks and >>innuendos on both myself and the OpenSS7 implementations. >> >>--brian >> >> > > Ok, so now finally agree that not checking the address parameters can make that the peer is not "able to establish associations in certain circumstances", as section 2.18.3 says. > > Well, this is progress.. > And now let's see about those problems/improvements... > > By the way. I perfectly know that you know what you are talking about. That's why I have completely read everything you have written in your mails... > > It is just the way you talk sometimes what I don't like... :-/ > > I doubly agree :> R > BR Iván Arias Rodríguez > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Mon Mar 10 15:01:54 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10728 for ; Mon, 10 Mar 2003 15:01:52 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2AJuWhs005892 for ; Mon, 10 Mar 2003 11:56:33 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2AJuVlO029948 for ; Mon, 10 Mar 2003 11:56:32 -0800 (PST) Received: from gw.openss7.com (IDENT:x6aV7sEiuaqtTyonRRc6OvXGG2q9P/7X@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2AJuVof005085 for ; Mon, 10 Mar 2003 11:56:37 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:bX/eO/x/XTsoKGBcKsdzF+DiFt/NDIv3@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2AJlsD19236; Mon, 10 Mar 2003 12:47:54 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2AJlrH18747; Mon, 10 Mar 2003 12:47:53 -0700 Date: Mon, 10 Mar 2003 12:47:53 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: rrs@cisco.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030310124753.A17174@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Mon, Mar 10, 2003 at 03:17:27PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan, I don't know that I agree with 2.6 yet... Consider your last case. If Interface C is unreachable from A, and following 2.6 and sending the INIT-ACK to C instead of D, the association will fail to form. INIT A:1000->C:1000 INIT D:1000->A:1000 ----------------------\ /----------------------- \ / \ / / \ / \ C unreachable <---------------------/ \--------------X INIT-ACK A:1000->C:1000 C unreachable ------------------------------------------>X Following RFC 2960, the association would form regardless of whether C was reachable from A. INIT A:1000->C:1000 INIT D:1000->A:1000 ----------------------\ /----------------------- \ / \ / / \ / \ C unreachable <---------------------/ \--------------X INIT-ACK A:1000->D:1000 ----------------------------------------------------> COOKIE-ECHO D:1000->A:1000 <---------------------------------------------------- COOKIE-ACK A:1000->D:1000 ----------------------------------------------------> Section 2.6 appears to sacrifice reliability in the INIT process by treating all interfaces except the interface that A has sent an INIT to as though they were an attacker. Is it the intention of 2.6 to sacrifice this collision case if interface C is temporarily unreachable? Our current implementation does not sacrifice this case (or the case where C is reachable) if D is supplied to connect(). The current implementation sacrifices the cases where D is not supplied to connect(). For applications that can have a knowledge of D (e.g. from DNS lookup or static assignment) and requires a reliable INIT process our current implementation is superior to IG 2.6. Where the application has no knowledge of D and does not care about a reliable INIT process, 2.6 is superior to our current implementation. Is this not a tradeoff that depends on the application? --brian On Mon, 10 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > > > > Randall, > > > > Here's what I doing differently (but I still think that you owe > > me and the OpenSS7 implementation an apology): > > > > When sending the INIT-ACK the implementation is choosing a new > > verification tag instead of using the verification tag of the > > existing TCB. But the implementation also follows the RFC in > > that the INIT-ACK is sent back to the source of the INIT. If > > Yes, this is what the RFC says, but it has been changed by the IG. > > > the VT from the TCB was sent, it would be handed to the attacker > > (in the initiate tag rather than tie-tags). The OpenSS7 > > implementation sacrifices the collision case (rare) to protect > > all other association initializations. > > Just because of this it is why section 5.2 has been modified... > > > The IG is not normative. This is why I asked on tsvwg why it > > had not been advanced. There are many clauses in the IG that > > are clarifications and interpretations of RFC 2960 and can be > > implemented without the IG being normative, but 2.6 is not one > > of them. RFC 2960 tells me that I MUST send the INIT-ACK back > > to the source of the INIT. > > Since we detected this problem, that's why it was modified. > > > To follow 2.6 I need to find the existing TCB to use the VT from > > the TCB in the initiate tag of the INIT-ACK and send the > > INIT-ACK to C instead of D. But this still does not justify the > > statement in 2.18, because it is only necessary to consider the > > source address list in the INIT iff there exists one or more > > TCBs for the port pair and local address, and iff one ore more > > of those TCBs is in the COOKIE-WAIT state, (i.e. only if a > > collision indeed can exist). It is certainly not necessary to > > consider and arbitrarily long and suspect source address list on > > all INITs, or even on INITs where there is no TCB for the port > > pair and destination address, or even on INITs where there is no > > TCB for the port pair and destination address in the COOKIE-WAIT > > state. To consider an arbitrarily long and suspect source > > address list on all INITs would open an implementation up to > > DoS attacks with long source address lists. > > This is perfectly reasonable. You don't really need to take a look first to the address and then to the ports. You can do it as you like... > > You are right that if there isn't an open association whose source/destination ports match those of the INIT, not matter how deep you dig inside the address parameters, the INIT will never belong to any of the existing associations. > > But the text in section 2.18 doesn't say that you have to check the addresses anyway. It tells you that the addresses inside the parameters are as valid as the source address to identify the association. In other words, if you are checking the source address of the INIT (I guess that if you do that that's because either you check first the addresses -which I would say it is not the wiser thing to do-, or because you have already found a matching port pair), don't stop there and also use the addresses inside. > > > So I still think that the new paragraph D) in IG 2.18 is > > unwarranted. It is OK to let implementations search how they > > will as long as they meet the other requirements. > > I think there could be a change. So far we were thinking about something similar to: > > D) An INIT or INIT ACK chunk MUST be treated as belonging > to an already established association (or one in the > process of being established) if the use of any of the > valid address parameters contained within the chunk > would identify an existing TCB. > > > > I will illustrate the need for the "extra" COOKIE-ECHO to limit > > a DoS attack for the INIT-ACK case to address Caitlin's example > > in a separate mail. > > > > I will also address in a separate mail the new text for section > > 5.2.1 in section 2.6. There, I believe that it is unnecessary > > for the receiver of an INIT to reject it just because it includes > > new addresses when the packet source address of the INIT is one > > of the existing addresses of the TCB. Also, that to not send an > > INIT-ACK again opens a DoS attack (where the existing TCB in the > > COOKIE-ECHOED state is for an association to a malicous endpoint). > > > > Please consider that--just maybe--I know what I'm talking about > > (yes, I can right sometimes ;), and please skip the attacks and > > innuendos on both myself and the OpenSS7 implementations. > > > > --brian > > Ok, so now finally agree that not checking the address parameters can make that the peer is not "able to establish associations in certain circumstances", as section 2.18.3 says. > > And now let's see about those problems/improvements... > > By the way. I perfectly know that you know what you are talking about. That's why I have completely read everything you have written in your mails... > > It is just the way you talk sometimes what I don't like... :-/ > > BR Iván Arias Rodríguez -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-5.cisco.com Mon Mar 10 16:38:25 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15522 for ; Mon, 10 Mar 2003 16:38:23 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2ALYehs022563 for ; Mon, 10 Mar 2003 13:34:41 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2ALYe3A009568 for ; Mon, 10 Mar 2003 13:34:40 -0800 (PST) Received: from gw.openss7.com (IDENT:YUWriyV6muG2fbuZi/ATTYPUUrjrUVQ7@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2ALY8AL026855 for ; Mon, 10 Mar 2003 13:34:16 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:/SUxwkoR7CuG9kpp1CjxTC4HMfHOzJPI@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2ALRsD20687; Mon, 10 Mar 2003 14:27:54 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2ALRsA21280; Mon, 10 Mar 2003 14:27:54 -0700 Date: Mon, 10 Mar 2003 14:27:54 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-08.txt Message-ID: <20030310142754.A20295@openss7.org> Reply-To: bidulock@openss7.org References: <200303041230.HAA15062@ietf.org> <20030309221449.A1547@openss7.org> <3E6C76F4.4050003@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E6C76F4.4050003@cisco.com>; from rrs@cisco.com on Mon, Mar 10, 2003 at 05:28:52AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, When I said that the IG is not normative, I meant the current draft. It is my understanding that an implementation is not compelled to follow a draft document. Is that correct? --brian On Mon, 10 Mar 2003, Randall Stewart (cisco) wrote: > Brian: > > I stated to you (I think this is who you refer to) that our intention > is to make it normative whenever it gets incorporated into > a new RFC... You should know that all drafts are not normative > until they finish the IETF process. > > Our discussion was in particular about text that you objected to.. > my interpretation of your query was that you thought the text > could never be normative... and I just don't think that is true.. since > our intentions are to close the I-G soon... > > R > > Brian F. G. Bidulock wrote: > > >I have been told by an author of this document that this document is normative. > > > >Is this the case? > > > >Could someone please point me to the place in the IETF process > >where a draft document is considered normative before advancing? > > > >--brian > > > > > >On Tue, 04 Mar 2003, 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 Transport Area Working Group Working Group of the IETF. > >> > >> Title : Stream Control Transmission Protocol (SCTP) > >> Implementors Guide > >> Author(s) : R. Stewart, L. Ong et al. > >> Filename : draft-ietf-tsvwg-sctpimpguide-08.txt > >> Pages : 64 > >> Date : 2003-3-3 > >> > >>This document contains a compilation of all defects found up until > >>the publishing of this document for the Stream Control Transmission > >>Protocol (SCTP) RFC2960 [3]. These defects may be of an editorial or > >>technical nature. This document may be thought of as a companion > >>document to be used in the implementation of SCTP to clarify errors > >>in the original SCTP document. > >>This document updates RFC2960 [3] and text within this document > >>supersedes the text found in RFC2960 [3]. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-08.txt > >> > >>To remove yourself from the IETF Announcement list, send a message to > >>ietf-announce-request with the word unsubscribe in the body of the message. > >> > >>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-tsvwg-sctpimpguide-08.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-tsvwg-sctpimpguide-08.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. > >> > >> > > > > > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Mon Mar 10 16:43:25 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15662 for ; Mon, 10 Mar 2003 16:43:24 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2ALeQ0E022613 for ; Mon, 10 Mar 2003 13:40:26 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2ALeOC9014249 for ; Mon, 10 Mar 2003 13:40:24 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2ALdsAL029227 for ; Mon, 10 Mar 2003 13:40:00 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2ALGpF20716 for ; Mon, 10 Mar 2003 23:16:51 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 23:13:24 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 23:13:24 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 23:13:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Mon, 10 Mar 2003 23:13:23 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLnP02kNM2p6kxITF6MO5dpUxPvywAAIBJQ From: To: Cc: , , X-OriginalArrivalTime: 10 Mar 2003 21:13:24.0432 (UTC) FILETIME=[E2D95D00:01C2E749] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA15662 Brian, > > Ivan, > > I don't know that I agree with 2.6 yet... We finally agreed that the peer is not "able to establish associations in certain circumstances"... My mother tongue is not English, but I understood that from your "at very minor expense of this one unnecessary corner case [the INIT collision]" in one of your mails... > Consider your last case. If Interface C is unreachable > from A, and following 2.6 and sending the INIT-ACK to C > instead of D, the association will fail to form. > > INIT A:1000->C:1000 INIT D:1000->A:1000 > ----------------------\ /----------------------- > \ / > \ / > / \ > / \ C unreachable > <---------------------/ \--------------X > > INIT-ACK A:1000->C:1000 C unreachable > ------------------------------------------>X > And if C is unreachable, why including it in the INIT? Ok, let's say that SCTP doesn't know about the state of the interfaces... > Following RFC 2960, the association would form regardless > of whether C was reachable from A. > > INIT A:1000->C:1000 INIT D:1000->A:1000 > ----------------------\ /----------------------- > \ / > \ / > / \ > / \ C unreachable > <---------------------/ \--------------X > > INIT-ACK A:1000->D:1000 > ----------------------------------------------------> > COOKIE-ECHO D:1000->A:1000 > <---------------------------------------------------- > COOKIE-ACK A:1000->D:1000 > ----------------------------------------------------> > > Section 2.6 appears to sacrifice reliability in the INIT > process by treating all interfaces except the interface > that A has sent an INIT to as though they were an attacker. It seems that the case of INIT collision AND an unreachable (but still included in the list of valid addresses) is more probable than the case of INIT collision AND... nothing else... :-/ > Is it the intention of 2.6 to sacrifice this collision case > if interface C is temporarily unreachable? Come on, Brian, you are sacrificing the other more general case... your implementation works in this case, but not in the other, so? Or... let me see... hmmm... I *think* this is actually what your implementation does (I might be wrong): Host A Host C/D TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB A:1000 \ A:1000->C:1000 D:1000->A:1000 / C,D:1000 C:1000 \ / A:1000 VTloc:W \ / VTloc:X VTpeer:0 \ / VTpeer:0 C-WAIT \ / C-WAIT \--------------------\ /--------------------/ \/ /\ / \ (1) <-------------------------/ \-------------------------> X \ INIT ACK VT:X IT:Y \ A:1000->D:1000 \ VTloc:Y VTpeer:X \TTloc:0 TTpeer:0 \ \ \--------------------\ \ \ \ \-------------------------> COOKIE ECHO VT:Y / TCB D:1000->A:1000 / C,D:1000 VTloc:Y VTpeer:X / A:1000 TTloc:0 TTpeer:0/ VTloc:X / VTpeer:Y / C-ECHOED /--------------------/ / / / (2) X<-------------------------/ At (1) your implementation as usual doesn't recognized the peer and sends an INIT ACK with a new IT. At (2), the VT doesn't help you to find any TCB. However, there is already a conflicting TCB... I think there are two possibilities: a) If you go through the address list inside the COOKIE, you will find it, but, since none of the VT match and the Tie Tags are set to 0, you discard it. Bad, the association doesn't come up... b) You create a new TCB (and send back a COOKIE ACK not included in the drawing), and then you take a look to the other existing TCBs (you must do this, otherwise you take the risk of having two conflicting established associations) and you see one in conflict. So, you happily decide that this new TCB "includes" the old one, and you tell to the upper user that its association with C is established. Everything looks perfect. However, so far Host C/D has not proven at all that it owns address C. Conclusion? Much worse. Host A thinks that it is speaking with C, while he could be speaking with an attacker that simply included address C in the list. This possibility needs: 1) either the adapter C is broken or at least the INIT from Host A is delayed enough time, 2) the attacker knows you are about to connect with C. You have insisted that these scenario is possible (and even more, you were scared about the possibility of not only all this happening, but also trying to connect with the "real" C and with the attacker, D, at about the same time). I hope you don't say now that this is an extreme corner case, since yours was even more weird. So, which option does your implementation choose, the bad or the worse? > Our current implementation does not sacrifice this case As I think, it sacrifices both, or it is open to attacks... As I said above, I might be wrong as well... it is late and I'm tired... :-0 > (or the case where C is reachable) if D is supplied to > connect(). The current implementation sacrifices the cases > where D is not supplied to connect(). See above... > For applications that can have a knowledge of D (e.g. from > DNS lookup or static assignment) and requires a reliable > INIT process our current implementation is superior to Now that I think about it... I think this could be an improvement for the INIT collision scenario... We could say that instead of sending the INIT ACK to the destination address of the previously sent INIT, we could use any of the "known addresses". The point is that the RFC always considers that you only know one of the peer's addresses... But this change would be completely equivalent and more general. However, I don't know in how many places the RFC takes for granted that while in the COOKIE WAIT state you know only one of the peer's addresses... :-/ > IG 2.6. Where the application has no knowledge of D and > does not care about a reliable INIT process, 2.6 is superior > to our current implementation. See above... > Is this not a tradeoff that depends on the application? See above... BR Iván Arias Rodríguez > --brian From owner-extdom.sctp-impl@sj-core-2.cisco.com Mon Mar 10 18:12:44 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19975 for ; Mon, 10 Mar 2003 18:12:43 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2AN6uEY003704; Mon, 10 Mar 2003 15:06:56 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEJ03728; Mon, 10 Mar 2003 15:06:55 -0800 (PST) Message-ID: <3E6D1A8E.6030803@cisco.com> Date: Mon, 10 Mar 2003 17:06:54 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: bidulock@openss7.org, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ivan: One or two minor points I will add below :> Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > > >>Ivan, >> >>I don't know that I agree with 2.6 yet... >> >> > > We finally agreed that the peer is not "able to establish associations in certain circumstances"... My mother tongue is not English, but I understood that from your "at very minor expense of this one unnecessary corner case [the INIT collision]" in one of your mails... > > > >>Consider your last case. If Interface C is unreachable >>from A, and following 2.6 and sending the INIT-ACK to C >>instead of D, the association will fail to form. >> >>INIT A:1000->C:1000 INIT D:1000->A:1000 >>----------------------\ /----------------------- >> \ / >> \ / >> / \ >> / \ C unreachable >><---------------------/ \--------------X >> >>INIT-ACK A:1000->C:1000 C unreachable >>------------------------------------------>X >> >> >> > > And if C is unreachable, why including it in the INIT? Ok, let's say that SCTP doesn't know about the state of the interfaces... > > > >>Following RFC 2960, the association would form regardless >>of whether C was reachable from A. >> >>INIT A:1000->C:1000 INIT D:1000->A:1000 >>----------------------\ /----------------------- >> \ / >> \ / >> / \ >> / \ C unreachable >><---------------------/ \--------------X >> >>INIT-ACK A:1000->D:1000 >>----------------------------------------------------> >> COOKIE-ECHO D:1000->A:1000 >><---------------------------------------------------- >>COOKIE-ACK A:1000->D:1000 >>----------------------------------------------------> >> >>Section 2.6 appears to sacrifice reliability in the INIT >>process by treating all interfaces except the interface >>that A has sent an INIT to as though they were an attacker. >> >> > > It seems that the case of INIT collision AND an unreachable (but still included in the list of valid addresses) is more probable than the case of INIT collision AND... nothing else... :-/ > > One little addition.. consider the case where you just send to C.. with it down and no INIT collision is occuring.. guess what? You have the same problem... > > >>Is it the intention of 2.6 to sacrifice this collision case >>if interface C is temporarily unreachable? >> >> > > Come on, Brian, you are sacrificing the other more general case... your implementation works in this case, but not in the other, so? > > Or... let me see... hmmm... I *think* this is actually what your implementation does (I might be wrong): > > >Host A Host C/D > >TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >A:1000 \ A:1000->C:1000 D:1000->A:1000 / C,D:1000 >C:1000 \ / A:1000 >VTloc:W \ / VTloc:X >VTpeer:0 \ / VTpeer:0 >C-WAIT \ / C-WAIT > \--------------------\ /--------------------/ > \/ > /\ > / \ > (1) <-------------------------/ \-------------------------> X > > \ INIT ACK VT:X IT:Y > \ A:1000->D:1000 > \ VTloc:Y VTpeer:X > \TTloc:0 TTpeer:0 > \ > \ > \--------------------\ > \ > \ > \ > \-------------------------> > > COOKIE ECHO VT:Y / TCB > D:1000->A:1000 / C,D:1000 > VTloc:Y VTpeer:X / A:1000 > TTloc:0 TTpeer:0/ VTloc:X > / VTpeer:Y > / C-ECHOED > /--------------------/ > / > / > / > (2) X<-------------------------/ > > > At (1) your implementation as usual doesn't recognized the peer and sends an INIT ACK with a new IT. > > At (2), the VT doesn't help you to find any TCB. However, there is already a conflicting TCB... I think there are two possibilities: > > a) If you go through the address list inside the COOKIE, you will find it, but, since none of the VT match and the Tie Tags are set to 0, you discard it. Bad, the association doesn't come up... > > b) You create a new TCB (and send back a COOKIE ACK not included in the drawing), and then you take a look to the other existing TCBs (you must do this, otherwise you take the risk of having two conflicting established associations) and you see one in conflict. So, you happily decide that this new TCB "includes" the old one, and you tell to the upper user that its association with C is established. Everything looks perfect. > However, so far Host C/D has not proven at all that it owns address C. Conclusion? Much worse. Host A thinks that it is speaking with C, while he could be speaking with an attacker that simply included address C in the list. This possibility needs: 1) either the adapter C is broken or at least the INIT from Host A is delayed enough time, 2) the attacker knows you are about to connect with C. > You have insisted that these scenario is possible (and even more, you were scared about the possibility of not only all this happening, but also trying to connect with the "real" C and with the attacker, D, at about the same time). I hope you don't say now that this is an extreme corner case, since yours was even more weird. > > > So, which option does your implementation choose, the bad or the worse? > > > >>Our current implementation does not sacrifice this case >> >> > > As I think, it sacrifices both, or it is open to attacks... As I said above, I might be wrong as well... it is late and I'm tired... :-0 > > > >>(or the case where C is reachable) if D is supplied to >>connect(). The current implementation sacrifices the cases >>where D is not supplied to connect(). >> >> > > See above... > > > >>For applications that can have a knowledge of D (e.g. from >>DNS lookup or static assignment) and requires a reliable >>INIT process our current implementation is superior to >> >> > > Now that I think about it... I think this could be an improvement for the INIT collision scenario... We could say that instead of sending the INIT ACK to the destination address of the previously sent INIT, we could use any of the "known addresses". The point is that the RFC always considers that you only know one of the peer's addresses... But this change would be completely equivalent and more general. However, I don't know in how many places the RFC takes for granted that while in the COOKIE WAIT state you know only one of the peer's addresses... :-/ > > Yes, that would be completely consistent with what the IG is attempting to do.. I think for the next pass this little tweak in wording is probably ok... and then would allow (if you knew any other by whatever means) to use it... When we did the telcom geneva show with our proto-type rserpool implementation we had all the addresses registered.. so if an endpoint could not initialize to "C" then when it failed the ULP (ASAP) could re-init to "D"... of course if there was an alternate that might be prefereable.. since C/D is already running degraded (at least from A's perspective)... I do have to give Brian credit. He is like the man that screams if a flame is brought into the house, his whole house will catch fire.. so we MUST have protection from this fire... then in the next breath screams I am cold we MUST have fire in the house now... :-> I don't know who he is trying to fool... all that he wants is to make what he is doing in his implementation what is specified... and this is just not going to happen. Has it is, we have seen through this discussion he is not following the current RFC2960's requirment to respond to an INIT (in COOKIE-WAIT state) with the same Initiation Tag... (the very section he is complaining about that the IG is changing above)... R > > >>IG 2.6. Where the application has no knowledge of D and >>does not care about a reliable INIT process, 2.6 is superior >>to our current implementation. >> >> > > See above... > > > >>Is this not a tradeoff that depends on the application? >> >> > > See above... > > BR Iván Arias Rodríguez > > > >>--brian >> > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Mon Mar 10 18:53:18 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21315 for ; Mon, 10 Mar 2003 18:53:16 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2ANnshs016357 for ; Mon, 10 Mar 2003 15:49:55 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2ANnBEh012927 for ; Mon, 10 Mar 2003 15:49:12 -0800 (PST) Received: from gw.openss7.com (IDENT:1NdMzYZLstrEKF19of1IZEBZvFvLJqwe@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h2ANlf2W002086 for ; Mon, 10 Mar 2003 15:47:43 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:U6Y6IRzY9L89YNdsOWv5Jdltum0kq3aK@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2ANgUD22593; Mon, 10 Mar 2003 16:42:30 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2ANgUr24695; Mon, 10 Mar 2003 16:42:30 -0700 Date: Mon, 10 Mar 2003 16:42:30 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030310164230.A24011@openss7.org> Reply-To: bidulock@openss7.org References: <3E6D1A8E.6030803@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E6D1A8E.6030803@cisco.com>; from rrs@cisco.com on Mon, Mar 10, 2003 at 05:06:54PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Mon, 10 Mar 2003, Randall Stewart (cisco) wrote: > Ivan: > > One or two minor points I will add below :> > > Ivan.Arias-Rodriguez@nokia.com wrote: > > > Brian, > > > > > > > >>Ivan, > >> > >>I don't know that I agree with 2.6 yet... > >> > >> > > > > We finally agreed that the peer is not "able to establish associations in certain circumstances"... My mother tongue is not English, but I understood that from your "at very minor expense of this one unnecessary corner case [the INIT collision]" in one of your mails... > > > > > > > >>Consider your last case. If Interface C is unreachable > >>from A, and following 2.6 and sending the INIT-ACK to C > >>instead of D, the association will fail to form. > >> > >>INIT A:1000->C:1000 INIT D:1000->A:1000 > >>----------------------\ /----------------------- > >> \ / > >> \ / > >> / \ > >> / \ C unreachable > >><---------------------/ \--------------X > >> > >>INIT-ACK A:1000->C:1000 C unreachable > >>------------------------------------------>X > >> > >> > >> > > > > And if C is unreachable, why including it in the INIT? Ok, let's say that SCTP doesn't know about the state of the interfaces... > > > > > > > >>Following RFC 2960, the association would form regardless > >>of whether C was reachable from A. > >> > >>INIT A:1000->C:1000 INIT D:1000->A:1000 > >>----------------------\ /----------------------- > >> \ / > >> \ / > >> / \ > >> / \ C unreachable > >><---------------------/ \--------------X > >> > >>INIT-ACK A:1000->D:1000 > >>----------------------------------------------------> > >> COOKIE-ECHO D:1000->A:1000 > >><---------------------------------------------------- > >>COOKIE-ACK A:1000->D:1000 > >>----------------------------------------------------> > >> > >>Section 2.6 appears to sacrifice reliability in the INIT > >>process by treating all interfaces except the interface > >>that A has sent an INIT to as though they were an attacker. > >> > >> > > > > It seems that the case of INIT collision AND an unreachable (but still included in the list of valid addresses) is more probable than the case of INIT collision AND... nothing else... :-/ > > > > > > One little addition.. consider the case where you just send to C.. with it > down and no INIT collision is occuring.. guess what? You have the same > problem... Our implementation allows the ULP to send an address list to connect(). In this case (C,D). If the INIT times out on C, the implementation will send INIT to D. This makes the INIT process reliable in the case where C/D is listening and C is unreachable. So our implementation handles the non-collision case as well. > > > > > > >>Is it the intention of 2.6 to sacrifice this collision case > >>if interface C is temporarily unreachable? > >> > >> > > > > Come on, Brian, you are sacrificing the other more general case... your implementation works in this case, but not in the other, so? > > > > Or... let me see... hmmm... I *think* this is actually what your implementation does (I might be wrong): > > > > > >Host A Host C/D > > > >TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB > >A:1000 \ A:1000->C:1000 D:1000->A:1000 / C,D:1000 > >C:1000 \ / A:1000 > >VTloc:W \ / VTloc:X > >VTpeer:0 \ / VTpeer:0 > >C-WAIT \ / C-WAIT > > \--------------------\ /--------------------/ > > \/ > > /\ > > / \ > > (1) <-------------------------/ \-------------------------> X > > > > \ INIT ACK VT:X IT:Y > > \ A:1000->D:1000 > > \ VTloc:Y VTpeer:X > > \TTloc:0 TTpeer:0 > > \ > > \ > > \--------------------\ > > \ > > \ > > \ > > \-------------------------> > > > > COOKIE ECHO VT:Y / TCB > > D:1000->A:1000 / C,D:1000 > > VTloc:Y VTpeer:X / A:1000 > > TTloc:0 TTpeer:0/ VTloc:X > > / VTpeer:Y > > / C-ECHOED > > /--------------------/ > > / > > / > > / > > (2) X<-------------------------/ > > > > > > At (1) your implementation as usual doesn't recognized the peer and sends an INIT ACK with a new IT. > > > > At (2), the VT doesn't help you to find any TCB. However, there is already a conflicting TCB... I think there are two possibilities: > > > > a) If you go through the address list inside the COOKIE, you will find it, but, since none of the VT match and the Tie Tags are set to 0, you discard it. Bad, the association doesn't come up... > > > > b) You create a new TCB (and send back a COOKIE ACK not included in the drawing), and then you take a look to the other existing TCBs (you must do this, otherwise you take the risk of having two conflicting established associations) and you see one in conflict. So, you happily decide that this new TCB "includes" the old one, and you tell to the upper user that its association with C is established. Everything looks perfect. > > However, so far Host C/D has not proven at all that it owns address C. Conclusion? Much worse. Host A thinks that it is speaking with C, while he could be speaking with an attacker that simply included address C in the list. This possibility needs: 1) either the adapter C is broken or at least the INIT from Host A is delayed enough time, 2) the attacker knows you are about to connect with C. > > You have insisted that these scenario is possible (and even more, you were scared about the possibility of not only all this happening, but also trying to connect with the "real" C and with the attacker, D, at about the same time). I hope you don't say now that this is an extreme corner case, since yours was even more weird. > > > > > > So, which option does your implementation choose, the bad or the worse? > > > > > > > >>Our current implementation does not sacrifice this case > >> > >> > > > > As I think, it sacrifices both, or it is open to attacks... As I said above, I might be wrong as well... it is late and I'm tired... :-0 > > > > > > > >>(or the case where C is reachable) if D is supplied to > >>connect(). The current implementation sacrifices the cases > >>where D is not supplied to connect(). > >> > >> > > > > See above... > > > > > > > >>For applications that can have a knowledge of D (e.g. from > >>DNS lookup or static assignment) and requires a reliable > >>INIT process our current implementation is superior to > >> > >> > > > > Now that I think about it... I think this could be an improvement for the INIT collision scenario... We could say that instead of sending the INIT ACK to the destination address of the previously sent INIT, we could use any of the "known addresses". The point is that the RFC always considers that you only know one of the peer's addresses... But this change would be completely equivalent and more general. However, I don't know in how many places the RFC takes for granted that while in the COOKIE WAIT state you know only one of the peer's addresses... :-/ > > > > > Yes, that would be completely consistent with what the IG is attempting > to do.. I think for > the next pass this little tweak in wording is probably ok... and then > would allow (if you > knew any other by whatever means) to use it... When we did the telcom > geneva show > with our proto-type rserpool implementation we had all the addresses > registered.. so > if an endpoint could not initialize to "C" then when it failed the ULP > (ASAP) could > re-init to "D"... of course if there was an alternate that might be > prefereable.. since > C/D is already running degraded (at least from A's perspective)... > > I do have to give Brian credit. He is like the man that screams if a flame > is brought into the house, his whole house will catch fire.. so we MUST > have protection from this fire... then in the next breath screams > I am cold we MUST have fire in the house now... :-> > > I don't know who he is trying to fool... all that he wants is to make what > he is doing in his implementation what is specified... and this is just > not going to happen. Has it is, we have seen through this discussion he > is not following the current RFC2960's requirment to respond to > an INIT (in COOKIE-WAIT state) with the same Initiation Tag... (the very > section > he is complaining about that the IG is changing above)... You comments above are an example of the personal attacks and innuendos.... Please do not make remarks about my motives or character and focus on the technical issues involved. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-2.cisco.com Mon Mar 10 19:29:06 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22110 for ; Mon, 10 Mar 2003 19:29:04 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2B0IbEY012624; Mon, 10 Mar 2003 16:18:37 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEJ14675; Mon, 10 Mar 2003 16:18:36 -0800 (PST) Message-ID: <3E6D2B5C.90605@cisco.com> Date: Mon, 10 Mar 2003 18:18:36 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <3E6D1A8E.6030803@cisco.com> <20030310164230.A24011@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Mon, 10 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Ivan: >> >>One or two minor points I will add below :> >> >>Ivan.Arias-Rodriguez@nokia.com wrote: >> >> >> >>> Brian, >>> >>> >>> >>> >>> >>>>Ivan, >>>> >>>>I don't know that I agree with 2.6 yet... >>>> >>>> >>>> >>>> >>> We finally agreed that the peer is not "able to establish associations in certain circumstances"... My mother tongue is not English, but I understood that from your "at very minor expense of this one unnecessary corner case [the INIT collision]" in one of your mails... >>> >>> >>> >>> >>> >>>>Consider your last case. If Interface C is unreachable >>>> >>>> >>>>from A, and following 2.6 and sending the INIT-ACK to C >>> >>> >>>>instead of D, the association will fail to form. >>>> >>>>INIT A:1000->C:1000 INIT D:1000->A:1000 >>>>----------------------\ /----------------------- >>>> \ / >>>> \ / >>>> / \ >>>> / \ C unreachable >>>><---------------------/ \--------------X >>>> >>>>INIT-ACK A:1000->C:1000 C unreachable >>>>------------------------------------------>X >>>> >>>> >>>> >>>> >>>> >>> And if C is unreachable, why including it in the INIT? Ok, let's say that SCTP doesn't know about the state of the interfaces... >>> >>> >>> >>> >>> >>>>Following RFC 2960, the association would form regardless >>>>of whether C was reachable from A. >>>> >>>>INIT A:1000->C:1000 INIT D:1000->A:1000 >>>>----------------------\ /----------------------- >>>> \ / >>>> \ / >>>> / \ >>>> / \ C unreachable >>>><---------------------/ \--------------X >>>> >>>>INIT-ACK A:1000->D:1000 >>>>----------------------------------------------------> >>>> COOKIE-ECHO D:1000->A:1000 >>>><---------------------------------------------------- >>>>COOKIE-ACK A:1000->D:1000 >>>>----------------------------------------------------> >>>> >>>>Section 2.6 appears to sacrifice reliability in the INIT >>>>process by treating all interfaces except the interface >>>>that A has sent an INIT to as though they were an attacker. >>>> >>>> >>>> >>>> >>> It seems that the case of INIT collision AND an unreachable (but still included in the list of valid addresses) is more probable than the case of INIT collision AND... nothing else... :-/ >>> >>> >>> >>> >>One little addition.. consider the case where you just send to C.. with it >>down and no INIT collision is occuring.. guess what? You have the same >>problem... >> >> > >Our implementation allows the ULP to send an address list to connect(). >In this case (C,D). If the INIT times out on C, the implementation will >send INIT to D. This makes the INIT process reliable in the case where >C/D is listening and C is unreachable. So our implementation handles the >non-collision case as well. > > And I think Ivan's proposed wording covers that case just fine... IMO it is good for some applications but not suitable for a general purpose stack... > > >>> >>> >>> >>> >>>>Is it the intention of 2.6 to sacrifice this collision case >>>>if interface C is temporarily unreachable? >>>> >>>> >>>> >>>> >>> Come on, Brian, you are sacrificing the other more general case... your implementation works in this case, but not in the other, so? >>> >>> Or... let me see... hmmm... I *think* this is actually what your implementation does (I might be wrong): >>> >>> >>>Host A Host C/D >>> >>>TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB >>>A:1000 \ A:1000->C:1000 D:1000->A:1000 / C,D:1000 >>>C:1000 \ / A:1000 >>>VTloc:W \ / VTloc:X >>>VTpeer:0 \ / VTpeer:0 >>>C-WAIT \ / C-WAIT >>> \--------------------\ /--------------------/ >>> \/ >>> /\ >>> / \ >>> (1) <-------------------------/ \-------------------------> X >>> >>> \ INIT ACK VT:X IT:Y >>> \ A:1000->D:1000 >>> \ VTloc:Y VTpeer:X >>> \TTloc:0 TTpeer:0 >>> \ >>> \ >>> \--------------------\ >>> \ >>> \ >>> \ >>> \-------------------------> >>> >>> COOKIE ECHO VT:Y / TCB >>> D:1000->A:1000 / C,D:1000 >>> VTloc:Y VTpeer:X / A:1000 >>> TTloc:0 TTpeer:0/ VTloc:X >>> / VTpeer:Y >>> / C-ECHOED >>> /--------------------/ >>> / >>> / >>> / >>> (2) X<-------------------------/ >>> >>> >>> At (1) your implementation as usual doesn't recognized the peer and sends an INIT ACK with a new IT. >>> >>> At (2), the VT doesn't help you to find any TCB. However, there is already a conflicting TCB... I think there are two possibilities: >>> >>> a) If you go through the address list inside the COOKIE, you will find it, but, since none of the VT match and the Tie Tags are set to 0, you discard it. Bad, the association doesn't come up... >>> >>> b) You create a new TCB (and send back a COOKIE ACK not included in the drawing), and then you take a look to the other existing TCBs (you must do this, otherwise you take the risk of having two conflicting established associations) and you see one in conflict. So, you happily decide that this new TCB "includes" the old one, and you tell to the upper user that its association with C is established. Everything looks perfect. >>> However, so far Host C/D has not proven at all that it owns address C. Conclusion? Much worse. Host A thinks that it is speaking with C, while he could be speaking with an attacker that simply included address C in the list. This possibility needs: 1) either the adapter C is broken or at least the INIT from Host A is delayed enough time, 2) the attacker knows you are about to connect with C. >>> You have insisted that these scenario is possible (and even more, you were scared about the possibility of not only all this happening, but also trying to connect with the "real" C and with the attacker, D, at about the same time). I hope you don't say now that this is an extreme corner case, since yours was even more weird. >>> >>> >>> So, which option does your implementation choose, the bad or the worse? >>> >>> >>> >>> >>> >>>>Our current implementation does not sacrifice this case >>>> >>>> >>>> >>>> >>> As I think, it sacrifices both, or it is open to attacks... As I said above, I might be wrong as well... it is late and I'm tired... :-0 >>> >>> >>> >>> >>> >>>>(or the case where C is reachable) if D is supplied to >>>>connect(). The current implementation sacrifices the cases >>>>where D is not supplied to connect(). >>>> >>>> >>>> >>>> >>> See above... >>> >>> >>> >>> >>> >>>>For applications that can have a knowledge of D (e.g. from >>>>DNS lookup or static assignment) and requires a reliable >>>>INIT process our current implementation is superior to >>>> >>>> >>>> >>>> >>> Now that I think about it... I think this could be an improvement for the INIT collision scenario... We could say that instead of sending the INIT ACK to the destination address of the previously sent INIT, we could use any of the "known addresses". The point is that the RFC always considers that you only know one of the peer's addresses... But this change would be completely equivalent and more general. However, I don't know in how many places the RFC takes for granted that while in the COOKIE WAIT state you know only one of the peer's addresses... :-/ >>> >>> >>> >>> >>Yes, that would be completely consistent with what the IG is attempting >>to do.. I think for >>the next pass this little tweak in wording is probably ok... and then >>would allow (if you >>knew any other by whatever means) to use it... When we did the telcom >>geneva show >>with our proto-type rserpool implementation we had all the addresses >>registered.. so >>if an endpoint could not initialize to "C" then when it failed the ULP >>(ASAP) could >>re-init to "D"... of course if there was an alternate that might be >>prefereable.. since >>C/D is already running degraded (at least from A's perspective)... >> >>I do have to give Brian credit. He is like the man that screams if a flame >>is brought into the house, his whole house will catch fire.. so we MUST >>have protection from this fire... then in the next breath screams >> I am cold we MUST have fire in the house now... :-> >> >>I don't know who he is trying to fool... all that he wants is to make what >>he is doing in his implementation what is specified... and this is just >>not going to happen. Has it is, we have seen through this discussion he >>is not following the current RFC2960's requirment to respond to >>an INIT (in COOKIE-WAIT state) with the same Initiation Tag... (the very >>section >>he is complaining about that the IG is changing above)... >> >> > >You comments above are an example of the personal attacks and innuendos.... > > Well, why do you argue out of both sides of your mouth.. pick a direction and stick with it .. it becomes real hard to tell where you are sincere when you will send out conflicting emails.. its one thing if you said: Gee, I just realized that if we take care of that security issue I was concerned about it breaks this situation.. But I never see this from you.. if you have a change of opinion then please so note it.. don't try to argue both sides of an issue admit you have a change of mind if you do... otherwise you are making a inuendo that we are stupid and can't see what you are attempting to do... Stop the personel attacks and inuendos that you put towards Ivan, Caitlin and myself and you will see all of us treat you the same way... >Please do not make remarks about my motives or character and focus on >the technical issues involved. > I have always focused on the technical issues.. even though you have repeatedly attacked any postion I have taken.. to quote one of your previous email as a sample "I am not anti-SCTP, I am anti-Randall".... R > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Mon Mar 10 23:54:39 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26980 for ; Mon, 10 Mar 2003 23:54:34 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2B4pJhs002539 for ; Mon, 10 Mar 2003 20:51:19 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2B4pDo7012374 for ; Mon, 10 Mar 2003 20:51:18 -0800 (PST) Received: from gw.openss7.com (IDENT:4pnrHvaH1wc0c4vF0tPTkiYOzr5cMR+H@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h2B4nE2W020694 for ; Mon, 10 Mar 2003 20:49:14 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:b3T3MnKj9T2DeHMcdK5fbiV4+RC+RZHy@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2B4iHD28734; Mon, 10 Mar 2003 21:44:17 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2B3Y3Y02952; Mon, 10 Mar 2003 20:34:03 -0700 Date: Mon, 10 Mar 2003 20:34:02 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Caitlin Bestler , sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030310203402.B1806@openss7.org> Reply-To: bidulock@openss7.org References: <20030303103316.B15597@openss7.org> <20030308025453.A26345@openss7.org> <3E69DE4D.8010609@cisco.com> <20030309153850.B25482@openss7.org> <3E6C92B1.2070607@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E6C92B1.2070607@cisco.com>; from rrs@cisco.com on Mon, Mar 10, 2003 at 07:27:13AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Mon, 10 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > [snip] > >Here's the argument: > > > > > >Host A/B Host X Host C/D > > | | | > > |INIT A:1000 -> X:1000 | | > > |---------------------------------------------->| | > > |TCB1: | | > > |VT: X | | > > |PT: 0 | | > > |Loc: A:1000 | | > > |Rem: X:1000 | | > > |State: COOKIE-WAIT | | > > | | | > > |INIT A:1000 -> C:1000 | | > > |------------------------------------------------------->| > > |TCB2: | | > > |VT: Y | | > > |PT: 0 | | > > |Loc: A:1000 | | > > |Rem: C:1000 | | > > |State: COOKIE-WAIT | | > > | | | > > | INIT-ACK X:1000 -> A:1000 (D)| | > > |<----------------------------------------------| | > > |(TCB2 cannot be found on source addr list) | | > > |(TCB1 is found) | | > > | | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > |TCB1: | | > > |VT: X | | > > |PT: W | | > > |Loc: A:1000 | | > > |Rem: X:1000, D:1000 | | > > |State: COOKIE-ECHOED | | > > | X does not | | > > | send (or delays) | > > | COOKIE-ACK | | > > | | | > > | INIT-ACK C:1000 -> A:1000 (D)| > > |<-------------------------------------------------------| > > | | | > > > >Did you expect Host A to not send the COOKIE-ECHO for TCB2 and > >error the connection attempt to the user of TCB2? The user of > >TCB2 will retry, resulting in: > > > > Our implementation would recognize, when processing > the INIT-ACK of TCB2 (from C) and abort the association > setup.. so there would be no timer firing.. the user would > get an error... Abort which association setup? TCB2? Like so? This is what Caitlin wanted me to do as well. This is where the denial of service to legitimate host C occurs. | | | |ABORT A:1000 -> C:1000 | | |------------------------------------------------------->| > This is the same as if our association to X had gone > out and X had included C's address.. aka camping on > someone elses address. > > > > > | | | > > |T1-cookie timeout | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > > I dont understand how would you get a cookie-timeout on TCB2? > I could see a TCB2 t1-timeout.. but TCB2 has never seen the > INIT-ACK at this point. TCB2 received the INIT-ACK at above. > TCB1 holds X and D now (if I am following your case correctly) > and so when the arriving INIT-ACK from 'C' comes in you would > find TCB1... not 2.. so TCB2 is still in COOKIE-WAIT (not > COOKIE-ECHOED).. in our implementation (as I noted above) it > would be aborted... so the app would know something is up... TCB1 is in COOKIE-ECHOED state at above, it has already exchanged INIT-ACK and COOKIE-ECHO. Please take another look at it because it seems you have missed the INIT-ACK/COOKIE-ECHO exchange for TCB1 above. > > > > >Note that X can keep the T1-cookie timeout initially high by > >delaying the response to the INIT by RTO.Initial. T1-cookies > >double with each retransmission up to 60 seconds, so the > >sequence is 3sec, 6sec, 12sec, 24sec, 48sec, 60sec, 60sec, 60sec > >which is 273 seconds or about 4 minutes. This can be extended > >another 30 seconds by responding with a COOKIE-ACK just before > >the final timeout (or just before the application times out) > >and keeping the association established until after 30 more > >seconds a HEARTBEAT is sent to D which will illicit an abort and > >then go around again. > > > > A couple of questions on this scenario in general... > > A) Why is A contacting X AND C at the same time? Most likely > to gain some sort of service.. If so how is X going to know to > include D, or have any idea that C is being contacted? I would > think this is huge guess on the part of X and the probabilities > of getting this right would be somewhere in the order of > guessing a Vtag that is not dilluded 1 in 4 Billion.. Have to > ask M Tuexen if he could work up the probabilities :> X can know C's addresses if it can launch an INIT to it and receive an INIT-ACK. The probablilies are application specific. A "general purpose" stack would ensure that the attack was not possible regardless of application. > > B) You of course are assuming that X would pre-know the values that > are placed on RTO.Initial and max-retran... which of course are > user settable... granted using the defaults would be a good guess > but they may not be correct... RTO.Initial can be read by X with some accuracy. X just doesn't respond to an INIT and see how long it takes to get another. > C) What does X have to gain from this attack? Does it fool A into > thinking it is talking to C, I don't think so.. especially since this > app purposely contacted X... it had a reason to do so and is expecting > some service/reply from X. If X wants to deny converstations with > 'C' .. then this only works if you just so happen to begin to talk > to X and C at the same time. And if its just a plain ole DOS attack > it seems rather a foolish one... since up front generation of lots > of INIT's would be a far better choice... Basically I just can't see > what X is trying to gain in this scenario.. this is in the catagory > of what is the threat? and what is the results? The result is > that for some minutes you cannot contact one particular host if > you happen to contact two hosts at about the same time for > service and one of the hosts just so happens to guess/know > you are contacting the other one at the same time.. seems like > very very fine thread.. and a very minimum threat to me. But > lets continue anyway... X gains denial of service to an arbitrary list of hosts that it provides in its host address list for the period of time of the attack. If I had a click ad web service, I might want to take this attack on busy proxy servers to block access to ads of all my competitors. > > > > If the attacker does not SACK any > >received data then Host A may heartbeat X before D, or X could > >add several of bogus addresses into the list that will be > >heartbeated before D. > > > Why would it do that... A INIT/INIT-ACK counts as a RTT updating > thing as well as a COOKIE/COOKIE-ACK.. so in that sense > D is always the first one that A should HB.. X just reponds to the second INIT instead of the first and no RTT update is performed on the INIT/INIT-ACK. X can also read RTO.Initial from A by waiting for the second INIT. > > > Since T3-rtx is held at 60 seconds, X can > >get an average of 2 minutes out of each bogus destination in the > >source address list. > > > > Why do you say for each? Once the association is up, the first > bogus destination you HB will return an ABORT and knock > the whole thing down. No, no. By "bogus" destination I mean either an address controlled by X that will either return a HEARTBEAT-ACK or any address that will not return anything (pick some firewall completely ignoring protocol 132). > If X never sends anything to A then X will not even know when > the association collapses... A will get the ABORT from the > first bogus address, kill the assocation.. so then if C is > re-attempted you end up with that association coming up... A doesn't get ABORTs from the "bogus" addresses, only from the "spoofed" addresses. If X does not SACK any data, it is likely the first address to receive a HEARTBEAT. It can use this interval to determine A's heartbeat interval. Even though it never sees the ABORT, from knowledge of A's selection pattern for HEARTBEATS (code inspection or detection of how A heartbeats the "bogus" addresses) it can determine with some accuracy when the ABORT will occur. > > > The application may timeout before that > >but the timeouts of Internet applications are well known. > > > > | | | > > |T1-cookie timeout | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > | | | > > |INIT A:1000 -> C:1000 | | > > |------------------------------------------------------->| > > |TCB2: | | > > |VT: Y | | > > |PT: 0 | | > > |Loc: A:1000 | | > > |Rem: C:1000 | | > > |State: COOKIE-WAIT | | > > | INIT-ACK C:1000 -> A:1000 (D)| > > |<-------------------------------------------------------| > > > >Refused, because TCB exists for A:1000<-->D:1000? > > > > > > If the COOKIE-ACK has not yet been returned the association (as > you have pointed out) is not fully formed. As such I would think > another approach one could take in examining the INIT-ACK address > list is find both sets of TCB's and thus put both of them into > question.... we don't do this but one could quite easily.. > At the point we find the other assocaition and abort your > "TCB2" it would be a simple step to check its state.. if it is > not fully formed one could: > > 1) Abort both. A similar denial of service attack results: X can now send INIT after A with spoofed addresses and drop A's initialization attempt. > 2) Abort one (this is currently what we do). Which one? If you abort one in half the cases, you are wrong. If you abort the other, in the other half the cases you are wrong. And you would end up with an application specific tradeoff again. > 3) Look at the state of the existing one, if still forming > let the cookie-echo go out, but instead mark each > as suspect and needing HB before letting either > proceed to ESTABLISHED... if you will put a > delayed for security reasons... kind of like going > to an airport but not randomly being singled out > .. instead being singled out due to a problem. Then > when the COOKIE-ACK arrives back from each > you can HB each address before proceeding and > thus find out who is who ... But then you are sending the "extra" COOKIE-ECHO and the entire determination can be made at receipt of COOKIE-ACK (different source address lists) and there is no need to look in the source address list of the INIT or INIT-ACK. > > > > > | | | > > |T1-cookie timeout | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > | | | > > |T1-cookie timeout | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > | . | | > > | . repeat | | > > | . | | > > > >Note that X can find the address to include in its INIT merely > >by sending an INIT to C or D and getting an INIT-ACK. > > > > > > > And then guessing who is going to contact me at the same > exact time that it is contacting C or D... X does not need to guess who is going to contact it. It can attack every host that contacts it. > > > >If the INIT-ACK is not refused, and a COOKIE-ECHO is returned > >(the "extra" packet), the following occurs: > > > > > >Host A/B Host X Host C/D > > | | | > > |INIT A:1000->X:1000 | | > > |---------------------------------------------->| | > > |TCB1: | | > > |VT: X | | > > |PT: 0 | | > > |Loc: A:1000 | | > > |Rem: X:1000 | | > > |State: COOKIE-WAIT | | > > | | | > > |INIT A:1000->C:1000 | | > > |------------------------------------------------------->| > > |TCB2: | | > > |VT: Y | | > > |PT: 0 | | > > |Loc: A:1000 | | > > |Rem: C:1000 | | > > |State: COOKIE-WAIT | | > > | | | > > | INIT-ACK X:1000->A:1000 (D)| | > > |<----------------------------------------------| | > > |(TCB2 cannot be found on source addr list) | | > > |(TCB1 is found) | | > > | | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > |TCB1: X does not | | > > |VT: X send (or delays) | > > |PT: W COOKIE-ACK | | > > |Loc: A:1000 | | > > |Rem: X:1000, D:1000 | | > > |State: COOKIE-ECHOED | | > > | INIT-ACK C:1000->A:1000 (D)| > > |<-------------------------------------------------------| > > | | | > > |COOKIE-ECHO A:1000->C:1000 | | > > |------------------------------------------------------->| > > |TCB2: | | > > |VT: X | | > > |PT: Z | | > > |Loc: A:1000 | | > > |Rem: C:1000, D:1000 | | > > |State: COOKIE-ECHOED | | > > | COOKIE-ACK C:1000->A:1000| > > |<-------------------------------------------------------| > > |TCB2: | | > > |VT: X | | > > |PT: Z | | > > |Loc: A:1000 | | > > |Rem: C:1000, D:1000 | | > > |State: ESTABLISHED | | > > | | | > > |(Discard TCB1, inform user) (attacker thwarted)| | > > | | | > > > >What this would do is force attacker X to reply quickly with > >a COOKIE-ACK in order to block the legitimate host as in: > > > > But how do you still know which is the hacker and which > is the legit server is it X/D or C/D? In this case you > are saying its whoever gets a COOKIE-ACK to me > first... this is not good.. since you can't tie the two associations > (by your refusal to look in the INIT/INIT-ACK) you can't > do anything but hope that the real user is faster or closer... > Instead one can do as I state above in <3> hmm I think > I will look into getting this coded into the BSD implementation > seems like a good general solution to the issue... Looking at the sources address list and finding the other TCB does nothing to help with the situation. You still do not know which is the attacker and which is the legitimate host. The ordering of the messages is unimportant. One can only mark them both as suspect. But as noting can be done until after receiving COOKIE-ACK for both, and because the determination of suspect TCB can be made at that time, it is not necessary to consider the source address list on INIT or INIT-ACK, the determination can be deferred to when the second COOKIE-ACK is sent attempting to establish two associations with overlapping addresses. In the case that there is no malicious endpoint, only one COOKIE-ACK will be returned, and there is no need to mark TCBs suspect. If the second COOKIE-ACK is returned attempting to move the overlapping TCB to the ESTABLISHED state. HEARTBEAT cannot be used as you suppose, because both TCBs cannot be moved to the ESTABLISHED state (no two associations to an overlapping set of trasnport address combinations). When the first COOKIE-ACK is accepted, the TCB must move the the established state, making it impossible for the second to move to the established state. It is still a race between the attacker and the legtimate user on the COOKIE-ACK. One could HEARTBEAT the association immediately after receiving COOKIE-ACK, but the attacker can give an arbitrarily long list with "bogus" addresses that will pass the HEARTBEAT. RFC 2960 also does not permit more than one HEARTBEAT per heartbeat interval (and rightfully so). If many destinations where sent a HEARTBEAT immediately there would be a packet multiplication and the attacker would have another DoS attack by making A send out more than one HEARTBEAT for each message in the exchange. Nevertheless sending the COOKIE-ECHO in this case limits the attack (the COOKIE-ECHO timeout sequence is not possible), so I don't see that this is an "extra" COOKIE-ECHO as its purpose is to limit a vulnerability. > > > > >Host A/B Host X Host C/D > > | | | > > |INIT A:1000->X:1000 | | > > |---------------------------------------------->| | > > |TCB1: | | > > |VT: X | | > > |PT: 0 | | > > |Loc: A:1000 | | > > |Rem: X:1000 | | > > |State: COOKIE-WAIT | | > > | | | > > |INIT A:1000->C:1000 | | > > |------------------------------------------------------->| > > |TCB2: | | > > |VT: Y | | > > |PT: 0 | | > > |Loc: A:1000 | | > > |Rem: C:1000 | | > > |State: COOKIE-WAIT | | > > | | | > > | INIT-ACK X:1000->A:1000 (D)| | > > |<----------------------------------------------| | > > |(TCB2 cannot be found on source addr list) | | > > |(TCB1 is found) | | > > | | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > |TCB1: | | > > |VT: X | | > > |PT: W | | > > |Loc: A:1000 | | > > |Rem: X:1000, D:1000 | | > > |State: COOKIE-ECHOED | | > > | INIT-ACK C:1000->A:1000 (D)| > > |<-------------------------------------------------------| > > | | | > > | COOKIE-ACK X:1000->A:1000| | > > |<----------------------------------------------| | > > |TCB1: | | > > |VT: X | | > > |PT: W | | > > |Loc: A:1000 | | > > |Rem: X:1000, D:1000 | | > > |State: ESTABLISHED | | > > | | | > > |(Discard TCB2, inform user) | | > > | | | > > > >What this serves to do is put the attacker immediately into the > >ESTABLISHED state. If the attacker delays the COOKIE-ACK, the > >the legitimate peer will win the race and the attack is > >thwarted. The attacker cannot block for the initial 4 minutes, > >but can still place bogus addresses in the address list that > >will extend the period of time before a HEARTBEAT/ABORT sequence > >to D takes the association down. > > > And <3> above will avoid even this... > > > > >The major difference is that, in the ESTABLISHED state, the > >user of TCB1 can challenge the peer. In the COOKIE-ECHOED > >state, the user of TCB1 is blocked from communicating on the > >association and the ULP cannot assist in detecting the attack. > > > >Because X and D are indistinguishable to "A" ("A" has no prior > >knowledge of D or X), the only way to limit the attack is by > >sending the "extra" COOKIE-ECHO. So for the sake of security in > >this case, whether it be rare or not, it is better to send the > >extra COOKIE-ECHO than not. > > > Yes I see the point of the "extra" COOKIE-ECHO... in this one corner > case where you have non-completely overlapping INIT-ACK's aka > one is saying (X/D) the other (C/D).. Caitlins example was one where > you had the same overlap.. (C/D) and (C/D) in the INIT's.. using > <3> , one could easily tell if the two INIT-ACK's were completely > overlapping or partially overlapping ... this way the legitimate case > would NOT generate the extra COOKIE-ECHO and the "evil > server" case would so that one could proceed carefully and select > the correct address set for the peer... I.e. which is the evil > attacker X/D or C/D.... This is a interesting case and I do think > I will put it on my discussion list with Steve... if I can get some > of his time... I am not sure if it warrents writting the code to > handle it.. I will ask him before I get to deep into coding <3> :-0 Good, I think you follow me now. In our implementation where the first connect() has addresses (C,D) and the second has address (X), the attacker can always be identified and thwarted. Also, the implementation is not required to allow users to launch two inits in this fashion. (For example, I could delay sending the second INIT until there is no TCB in a state other than CLOSED or ESTABLISHED for the same local address and port pair. Then neither situation can occur, and there is no extra COOKIE-ECHO and no vulnerability. This would, of course, mean that there was no need for me to look in the source address list of the INIT or INIT-ACK. > > > > >Taking actions on unverifiable addresses in the source address > >list of INIT-ACKs is IMO quite naive. It opens the protocol up > >to an entire spectrum of addresss spoofing attacks. The only > >source address that is verified in INIT and INIT-ACK are the > >packet header source addresses. (The INIT packet source addres > >is verified by HMAC on COOKIE-ECHO; the INIT-ACK source address > >is verified by port pair, destination address and VT of the > >INIT-ACK matching those of the INIT.) > > > >The reason that 2.6 in the COOKIE-WAIT state works for collision > >is because the INIT-ACK with the existing VT is sent to the same > >address as the INIT. The receiver of the INIT already has the > >VT from the INIT so sending it in the INIT-ACK to same address > >does not expose the VT. > > > >In ths case, it is not possible for "A" to determine whether D > >truly belongs to X or whether it truly belongs to C without > >prior knowledge of address D. In the case where knowledge of > >address D can be easily obtained (e.g. DNS query), "A" is even > >the more vulnerable to X if it does not utilize the same > >readily available information about D. > > > >This is really scary. Server X can easily discover the secondary > >addresses service to which it wishes to block access by launching > >INITs to them and getting INIT-ACKs. Then server X can place > >_all_ the secondardy addresses in the address list (say 200 of > >them). > > > I have so far, not stumbled upon any such web servers.. aka that are > hackers that try to block other sites from being hit... Steve may know > a bit more.. I don't as yet believe this is that scary of a problem... > And if it is, the steps in <3> above can be used to correct it.. This is because TCP does not have the vulnerability because it does not naively consider an source address list. Such servers running SCTP will be vulnerable. > > I think a far more likely DOS attack would be when X gets a > INIT from A it then starts sending ton's of INIT's to A until > it finds a open port.. then it can generate lots and lots and lots > of INIT's from bogus addresses that nicely get you to do > the HMAC algorithms.. I would be much more concerned about > that aspect than this one .. but like I said Steve may have a different > perspective.... if so I will code up <3> for our implementation... The rate of INIT-ACKs sent to a given destination (the source address in the INIT packet, whether spoofed or not) can easily be measured and throttled and alarms generated. Nevertheless a system can be design so that all an attacker can do is "delay" the INIT process of legitimate assocations, not deny them. > > > >The one way that I can see to block the attack is by not > >permitting sockets bound to a static port address with > >SO_REUSEADDR to have their TCBs expanded by the INIT-ACK beyond > >the addresses that were supplied to connect() iff any other TCB > >is bound to the same static address (i.e., if resuse is actually > >in effect, for our imp that means if the bind bucket is not > >marked for fastreuse). Then the attack cannot form, and neither > >association will form unless sufficient prior knowledge was > >supplied to at least one of the two connect()s. This is > >certainly not too strong a restriction to place on socket users. > > > > > I see no reason for this restriction.. I don't either now. As I say above, the whole situation could be avoided by delaying sending the second INIT until the first association enters the CLOSED or ESTABLISHED state. There is no requirement in the RFC or IG that tells me when an implementation must send an INIT, so I can avoid the situation as I like. > > >This also means that the "extra" COOKIE-ECHO would never occur > >because the INIT-ACK can be refused on the basis of the bind > >characteristics. > > > >I still don't need to examine the address list when searching > >for a matching TCB, because any action taken on the address list > >is vulnerable to attack. The address list has not been > >verified. > > > >The only use for the packet source address in the INIT is to > >know where to send (in the collision corner case) the INIT-ACK, > >and to populate the cookie. > > > > > Far more likely of a corner case than your evil attacker server > (sort of passive agressive actually :>).... > > >The only use for the packet source address and source address > >list in the INIT-ACK is to expand unexpanded TCBs. (In this > >case, if sufficient address information is not supplied I will > >refuse to expand the TCB.) > > > >I hope this illustrates why it is unecessary (and is a secuirty > >risk) to examine the source address list of INIT-ACK. > > > > > [snip] > > A simple 'un-trusted' flag could be added to the socket-api to allow one > to declare.. I don't trust this peer HB every address before we converse.. Waiting to HB every address would still deny service for the period of time it takes to HB. > Not counting the corner case you illustrate above which I laid out > a solution that will immediately bring the bogus peer into suspect > even without a 'un-trusted' flag. > > One other thing I want to note... before I read your 2.6 issues.. > > 5.2.1 of RFC2960 states: > > "5.2.1 INIT received in COOKIE-WAIT or COOKIE-ECHOED State (Item B) > > This usually indicates an initialization collision, i.e., each > endpoint is attempting, at about the same time, to establish an > association with the other endpoint. > > Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an > endpoint MUST respond with an INIT ACK using the same parameters it > > > > Stewart, et al. Standards Track [Page 60] > > RFC 2960 Stream Control Transmission Protocol October 2000 > > > sent in its original INIT chunk (including its Initiation Tag, > unchanged). These original parameters are combined with those from > the newly received INIT chunk. The endpoint shall also generate a > State Cookie with the INIT ACK. The endpoint uses the parameters > sent in its INIT to calculate the State Cookie. > " > > Note the 'MUST respond with an INIT ACK using the same parameters it > sent in it soriginal INIT chunk (including its Initiation Tag," > > Your implementation, at least from your conversations in this > thread, does NOT do this... (in the double multi-homed case aka > the colliding INIT's that Ivan painted) No it doesn't because to do so for an untrusted address (when D is not provided to connect()) would hand the verification tag in the initiate tag to the attacker. When D is provided to connect (as a known and trusted address), I following this. This is what 2.6 was intended to fix. The 2.6 fix, however, causes association initializations to be unreliable and I think that there is yet another attack on 2.6 (because 2.6 does not stop the implementation from taking action on untrusted addresses from the souce address list). The only way that I see to close all the attacks is to not trust the source address list and take no action on it. This is what I have done from the start, ignored the source address list and provided a way for the user to provide a list of known and trusted addresses to connect(). I'll work up a DoS attack for 2.6 collision case for you in a separate mail. It should be easy. I will just replace C with the attacker (the place to which the INIT-ACK will be sent). Then X will forward the INIT-ACK to the legitimate host spoofed from A and X will have hijacked at least part of the association. --brian > > > R > > > > >I will talk to the "new addresses" of section 2.6 in a separate > >mail. (This one is already way too long ;) > > > >--brian > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Tue Mar 11 00:02:06 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27123 for ; Tue, 11 Mar 2003 00:02:04 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2B4wZ0E002974 for ; Mon, 10 Mar 2003 20:58:35 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2B4wYNY023139 for ; Mon, 10 Mar 2003 20:58:34 -0800 (PST) Received: from gw.openss7.com (IDENT:+uHcEk0ttnLCSYhy7UkTrJO0Bo5Zkg5W@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h2B4ua2W024868 for ; Mon, 10 Mar 2003 20:56:36 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:b3T3MnKj9T2DeHMcdK5fbiV4+RC+RZHy@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2B4pSD28817; Mon, 10 Mar 2003 21:51:29 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2B0RXN01821; Mon, 10 Mar 2003 17:27:33 -0700 Date: Mon, 10 Mar 2003 17:27:33 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: rrs@cisco.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030310172733.A1806@openss7.org> Reply-To: bidulock@openss7.org References: <3E6D1A8E.6030803@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Mon, Mar 10, 2003 at 11:13:23PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Mon, 10 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > > > > Ivan, > > > > I don't know that I agree with 2.6 yet... > > We finally agreed that the peer is not "able to establish associations in certain circumstances"... My mother tongue is not English, but I understood that from your "at very minor expense of this one unnecessary corner case [the INIT collision]" in one of your mails... > > > Consider your last case. If Interface C is unreachable > > from A, and following 2.6 and sending the INIT-ACK to C > > instead of D, the association will fail to form. > > > > INIT A:1000->C:1000 INIT D:1000->A:1000 > > ----------------------\ /----------------------- > > \ / > > \ / > > / \ > > / \ C unreachable > > <---------------------/ \--------------X > > > > INIT-ACK A:1000->C:1000 C unreachable > > ------------------------------------------>X > > > > And if C is unreachable, why including it in the INIT? Ok, let's say that SCTP doesn't know about the state of the interfaces... > > > Following RFC 2960, the association would form regardless > > of whether C was reachable from A. > > > > INIT A:1000->C:1000 INIT D:1000->A:1000 > > ----------------------\ /----------------------- > > \ / > > \ / > > / \ > > / \ C unreachable > > <---------------------/ \--------------X > > > > INIT-ACK A:1000->D:1000 > > ----------------------------------------------------> > > COOKIE-ECHO D:1000->A:1000 > > <---------------------------------------------------- > > COOKIE-ACK A:1000->D:1000 > > ----------------------------------------------------> > > > > Section 2.6 appears to sacrifice reliability in the INIT > > process by treating all interfaces except the interface > > that A has sent an INIT to as though they were an attacker. > > It seems that the case of INIT collision AND an unreachable (but still > included in the list of valid addresses) is more probable than the > case of INIT collision AND... nothing else... :-/ > > > Is it the intention of 2.6 to sacrifice this collision case > > if interface C is temporarily unreachable? > > Come on, Brian, you are sacrificing the other more general case... > your implementation works in this case, but not in the other, so? > > Or... let me see... hmmm... I *think* this is actually what your > implementation does (I might be wrong): Ivan, our implementation works in both cases if A supplies address C and D to the connect(). > > > Host A Host C/D > > TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB > A:1000 \ A:1000->C:1000 D:1000->A:1000 / C,D:1000 > C:1000 \ / A:1000 > VTloc:W \ / VTloc:X > VTpeer:0 \ / VTpeer:0 > C-WAIT \ / C-WAIT > \--------------------\ /--------------------/ This is where the difference is, when (C,D) is supplied to connect() in our implementation, the TCB starts out as: Host A Host C/D TCB \ INIT VT:0 IT:W INIT VT:0 IT:X / TCB A:1000 \ A:1000->C:1000 D:1000->A:1000 / C,D:1000 C:1000,D:1000 / A:1000 VTloc:W \ / VTloc:X VTpeer:0 \ / VTpeer:0 C-WAIT \ / C-WAIT \--------------------\ /--------------------/ \/ /\ / \ (1) <-------------------------/ \-------------------------> X TCB is found (A:1000-D:1000) without looking at source address (D is already in the TCB as a "known address"). \ INIT ACK VT:X IT:W \ A:1000->D:1000 \ VTloc:W VTpeer:X \TTloc:0 TTpeer:0 \ \ \--------------------\ This INIT-ACK is completely compliant with RFC 2960. It includes the IT of the existing TCB and it is sent back to the source of the INIT. By telling SCTP that D is trustworthy, fully compliant RFC 2960 behaviour is accomplished without vulnerability. \ \ \ \-------------------------> COOKIE ECHO VT:W / TCB D:1000->A:1000 / C,D:1000 VTloc:W VTpeer:X / A:1000 TTloc:0 TTpeer:0/ VTloc:X / VTpeer:W / C-ECHOED /--------------------/ / / / (2) <---------------------------/ \ \ VT matches, action B from Table 2 \ \ \ COOKIE-ACK \-----------------------------------------------------> > > At (1) your implementation as usual doesn't recognized the peer and > sends an INIT ACK with a new IT. When (C,D) are provided to connect(), the TCB is found as above and RFC 2960 compliant behavior is exhibited. > > At (2), the VT doesn't help you to find any TCB. However, there is > already a conflicting TCB... I think there are two possibilities: When (C,D) is provided to connect(), there is only ever one TCB. > > a) If you go through the address list inside the COOKIE, you will find > it, but, since none of the VT match and the Tie Tags are set to 0, you > discard it. Bad, the association doesn't come up... The TCB is found on address D because (C,D) was provided to connect(). It is unnecessary to use C from the source address list. > > b) You create a new TCB (and send back a COOKIE ACK not included in Not, when (C,D) is provide to connect(). Look more closely at the above. > the drawing), and then you take a look to the other existing TCBs (you > must do this, otherwise you take the risk of having two conflicting > established associations) and you see one in conflict. So, you happily > decide that this new TCB "includes" the old one, and you tell to the > upper user that its association with C is established. Everything > looks perfect. However, so far Host C/D has not proven at all that it > owns address C. Conclusion? Much worse. Host A thinks that it is > speaking with C, while he could be speaking with an attacker that > simply included address C in the list. This possibility needs: 1) > either the adapter C is broken or at least the INIT from Host A is > delayed enough time, 2) the attacker knows you are about to connect > with C. > You have insisted that these scenario is possible (and even more, you > were scared about the possibility of not only all this happening, but > also trying to connect with the "real" C and with the attacker, D, at > about the same time). I hope you don't say now that this is an extreme > corner case, since yours was even more weird. I agree that being unable to form a connection when an inteface is unavailable is more rare than the collision case. But Randall told me that the collision case was common. Which is it? I think that the probability of any vulnerability case is dependent upon the application and what the attacker does. Otherwise why would we spend so much time talking about corner cases? Besides, mission critical applications that have a high cost associated with failing to make connections and require 5 or 6 nines of availability cannot afford to have the INIT process fail because one interface is temporarily unreachable. Our implementation is indeed intended to work in these environments. It appears that 2.6 is not. > > So, which option does your implementation choose, the bad or the worse? In our implementation, the cost of forming the connection in all circumstances is having the ULP supply the list of "known addresses" to the connect() command. > > > Our current implementation does not sacrifice this case > > As I think, it sacrifices both, or it is open to attacks... As I said > above, I might be wrong as well... it is late and I'm tired... :-0 Yes, I believe you have it wrong, take a look again above. > > > (or the case where C is reachable) if D is supplied to > > connect(). The current implementation sacrifices the cases > > where D is not supplied to connect(). > > See above... > > > For applications that can have a knowledge of D (e.g. from > > DNS lookup or static assignment) and requires a reliable > > INIT process our current implementation is superior to > > Now that I think about it... I think this could be an improvement for > the INIT collision scenario... We could say that instead of sending > the INIT ACK to the destination address of the previously sent INIT, > we could use any of the "known addresses". The point is that the RFC > always considers that you only know one of the peer's addresses... But > this change would be completely equivalent and more general. However, > I don't know in how many places the RFC takes for granted that while > in the COOKIE WAIT state you know only one of the peer's addresses... > :-/ I don't see how this is so different from what our implementation does. It allows the ULP to provide a list of "known addresses" to the connect(). This allows the connection to be formed in both circumstances. It then also conforms to RFC 2960 behaviour (it sends the INIT-ACK to the source of the INIT). Also, it provide a list of addresses that SCTP can try to send an INIT to if the first INIT illicits no INIT-ACK (the case where C/D is listening but C is unreachable). If 2.6 permits me to send the INIT-ACK to any of these "known" addresses, then our implementation doesn't need to look in the source address list in the collision case because it can require the user to provide the list of "known" addresses and in fact does would not need to be changed to comply with 2.6. --brian > > > IG 2.6. Where the application has no knowledge of D and > > does not care about a reliable INIT process, 2.6 is superior > > to our current implementation. > > See above... > > > Is this not a tradeoff that depends on the application? > > See above... > > BR Iván Arias Rodríguez > > > --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-2.cisco.com Tue Mar 11 05:44:00 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15360 for ; Tue, 11 Mar 2003 05:43:57 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2BAQhEY004289 for ; Tue, 11 Mar 2003 02:26:43 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2BAQiLU010270 for ; Tue, 11 Mar 2003 02:26:44 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2BAQH2W015918 for ; Tue, 11 Mar 2003 02:26:22 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BA3VF18061 for ; Tue, 11 Mar 2003 12:03:31 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 12:00:04 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 12:00:04 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 12:00:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Tue, 11 Mar 2003 12:00:02 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLniutm0+j64mZUSaWdDz72T6PjNwAJWarw From: To: Cc: , , X-OriginalArrivalTime: 11 Mar 2003 10:00:03.0545 (UTC) FILETIME=[FC74FC90:01C2E7B4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA15360 Brian, > Ivan.Arias-Rodriguez, > > On Mon, 10 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > Brian, > > > > > > > > Ivan, > > > > > > I don't know that I agree with 2.6 yet... > > > > We finally agreed that the peer is not "able to > establish associations in certain circumstances"... My mother > tongue is not English, but I understood that from your "at > very minor expense of this one unnecessary corner case [the > INIT collision]" in one of your mails... > > > > > Consider your last case. If Interface C is unreachable > > > from A, and following 2.6 and sending the INIT-ACK to C > > > instead of D, the association will fail to form. > > > > > > INIT A:1000->C:1000 INIT D:1000->A:1000 > > > ----------------------\ /----------------------- > > > \ / > > > \ / > > > / \ > > > / \ C unreachable > > > <---------------------/ \--------------X > > > > > > INIT-ACK A:1000->C:1000 C unreachable > > > ------------------------------------------>X > > > > > > > And if C is unreachable, why including it in the INIT? > Ok, let's say that SCTP doesn't know about the state of the > interfaces... > > > > > Following RFC 2960, the association would form regardless > > > of whether C was reachable from A. > > > > > > INIT A:1000->C:1000 INIT D:1000->A:1000 > > > ----------------------\ /----------------------- > > > \ / > > > \ / > > > / \ > > > / \ C unreachable > > > <---------------------/ \--------------X > > > > > > INIT-ACK A:1000->D:1000 > > > ----------------------------------------------------> > > > COOKIE-ECHO D:1000->A:1000 > > > <---------------------------------------------------- > > > COOKIE-ACK A:1000->D:1000 > > > ----------------------------------------------------> > > > > > > Section 2.6 appears to sacrifice reliability in the INIT > > > process by treating all interfaces except the interface > > > that A has sent an INIT to as though they were an attacker. > > > > It seems that the case of INIT collision AND an > unreachable (but still > > included in the list of valid addresses) is more > probable than the > > case of INIT collision AND... nothing else... :-/ > > > > > Is it the intention of 2.6 to sacrifice this collision case > > > if interface C is temporarily unreachable? > > > > Come on, Brian, you are sacrificing the other more > general case... > > your implementation works in this case, but not in the > other, so? > > > > Or... let me see... hmmm... I *think* this is actually what your > > implementation does (I might be wrong): > > Ivan, our implementation works in both cases if A supplies > address C and D > to the connect(). Of course!! And mine, and Randall's, and everybody's! This is NOT what we are discussing... You are saying that you don't have to take a look to the address parameters in ANY case... You fail to agree that knowing all the addresses beforehand is a need to avoid it... Of course I don't need to take a look to the address parameters in that case? Why? I already know what's inside! Brian, please, stop going around! I'm too tired of you saying something without proving anything, catching you and showing that what you were saying is not completely true and that it is based on some assumptions... and then you changing the topic again, and again, from one point of view to the opposite, and never admitting that *something* that you said might be wrong (I know your answer to this "I was never wrong")... So, as we were speaking about that case, DON'T CHANGE it again, please... This conversation is stupid... Of course if you know all the addresses since the beginning this case WON'T EVER happen. Please, Brian, stop changing your "problematic case" every time we find (or at least is seems so, we might be as well wrong) that such problematic case is not what seems to be, or that there is even a worse one that you didn't show... So, PLEASE, answer to what I write and don't change AGAIN the initial conditions... > > Host A > Host C/D > > > > TCB \ INIT VT:0 IT:W INIT VT:0 > IT:X / TCB > > A:1000 \ A:1000->C:1000 > D:1000->A:1000 / C,D:1000 > > C:1000 \ > / A:1000 > > VTloc:W \ > / VTloc:X > > VTpeer:0 \ > / VTpeer:0 > > C-WAIT \ > / C-WAIT > > \--------------------\ /--------------------/ > > This is where the difference is, when (C,D) is supplied to > connect() in > our implementation, the TCB starts out as: Of course your implementation knows about the addresses... We have ALL this time saying that, of course, if you know the addresses in advance you don't need to take a look to them again... You don't even have to include them in the State Cookie... you already know them... you have already seen them... > > Host A > Host C/D > > TCB \ INIT VT:0 IT:W INIT VT:0 > IT:X / TCB > A:1000 \ A:1000->C:1000 > D:1000->A:1000 / C,D:1000 > C:1000,D:1000 > / A:1000 > VTloc:W \ > / VTloc:X > VTpeer:0 \ > / VTpeer:0 > C-WAIT \ > / C-WAIT > \--------------------\ /--------------------/ > \/ > /\ > / \ > (1) <-------------------------/ \-------------------------> X > > TCB is found (A:1000-D:1000) without looking at source > address (D is already > in the TCB as a "known address"). > > \ INIT ACK VT:X IT:W > \ A:1000->D:1000 > \ VTloc:W VTpeer:X > \TTloc:0 TTpeer:0 > \ > \ > \--------------------\ > > This INIT-ACK is completely compliant with RFC 2960. It > includes the IT of > the existing TCB and it is sent back to the source of the > INIT. By telling > SCTP that D is trustworthy, fully compliant RFC 2960 > behaviour is accomplished > without vulnerability. This is a DIFFERENT case to the one you initially proposed. Since you haven't found yet anything better to answer me, you just change the case... I have already seen that when you don't answer to something, it means that you admit that you might be wrong... Because, in any case, you basically never admit it... > > \ > \ > \ > \-------------------------> > > COOKIE ECHO > VT:W / TCB > > D:1000->A:1000 / C,D:1000 > VTloc:W > VTpeer:X / A:1000 > TTloc:0 > TTpeer:0/ VTloc:X > > / VTpeer:W > > / C-ECHOED > /--------------------/ > / > / > / > (2) <---------------------------/ > \ > \ VT matches, action B from Table 2 > \ > \ > \ COOKIE-ACK > \-----------------------------------------------------> > > > > At (1) your implementation as usual doesn't recognized > the peer and > > sends an INIT ACK with a new IT. > > When (C,D) are provided to connect(), the TCB is found as > above and RFC 2960 > compliant behavior is exhibited. My implementation is also able of doing so... and everybody's... The problem is that supplying all the addresses is not a MUST... > > > > At (2), the VT doesn't help you to find any TCB. > However, there is > > already a conflicting TCB... I think there are two > possibilities: > > When (C,D) is provided to connect(), there is only ever one TCB. Of course... > > > > a) If you go through the address list inside the > COOKIE, you will find > > it, but, since none of the VT match and the Tie Tags > are set to 0, you > > discard it. Bad, the association doesn't come up... > > The TCB is found on address D because (C,D) was provided to connect(). > It is unnecessary to use C from the source address list. > > > > > b) You create a new TCB (and send back a COOKIE ACK not > included in > > Not, when (C,D) is provide to connect(). Look more closely > at the above. Look more closely to your initial words and don't change them now... Brian, why being and engineer when you could be a politician? :-) > > the drawing), and then you take a look to the other > existing TCBs (you > > must do this, otherwise you take the risk of having two > conflicting > > established associations) and you see one in conflict. > So, you happily > > decide that this new TCB "includes" the old one, and > you tell to the > > upper user that its association with C is established. > Everything > > looks perfect. However, so far Host C/D has not proven > at all that it > > owns address C. Conclusion? Much worse. Host A thinks that it is > > speaking with C, while he could be speaking with an > attacker that > > simply included address C in the list. This possibility > needs: 1) > > either the adapter C is broken or at least the INIT > from Host A is > > delayed enough time, 2) the attacker knows you are > about to connect > > with C. > > > You have insisted that these scenario is possible (and > even more, you > > were scared about the possibility of not only all this > happening, but > > also trying to connect with the "real" C and with the > attacker, D, at > > about the same time). I hope you don't say now that > this is an extreme > > corner case, since yours was even more weird. > > I agree that being unable to form a connection when an > inteface is unavailable > is more rare than the collision case. But Randall told me > that the collision > case was common. Which is it? I think that the probability He didn't say it was common... At least what I understood was that it wasn't uncommon, which doesn't mean the same as far as I know... Saying that there is a case where it used to happen, doesn't mean that it is common... But again, you are changing words... :-/ > of any vulnerability > case is dependent upon the application and what the attacker > does. Otherwise > why would we spend so much time talking about corner cases? That's precisely what I think... Just state that iff you provide the list of addresses you don't need to inspect the address list... otherwise... it is your own risk... it may work most of the times... but it may not work sometimes... > Besides, mission critical applications that have a high cost > associated > with failing to make connections and require 5 or 6 nines of > availability > cannot afford to have the INIT process fail because one interface is > temporarily unreachable. Our implementation is indeed > intended to work in > these environments. It appears that 2.6 is not. Your application works? Please, tell me how it does so, WITHOUT knowing in advance the list of addresses... This is what you shown... You show the case, you say your implementation is better, and everybody claps... What you didn't say is that your implementation is better IFF you have MORE information than the other implementation... Of course then it is better... of course! > > So, which option does your implementation choose, the > bad or the worse? > > In our implementation, the cost of forming the connection in > all circumstances > is having the ULP supply the list of "known addresses" to the > connect() command. So? Either you look at the address list or you know the addresses... But since you CANNOT know the addresses in advance in all the circumstances, you have to take a look to the addresses... The point of all this discussion is that you have to know all the addresses of the peer when you receive the INIT to be able to act consistently. You knew them before? Ok, don't look at them again, they are the same ones... > > > Our current implementation does not sacrifice this case > > > > As I think, it sacrifices both, or it is open to > attacks... As I said > > above, I might be wrong as well... it is late and I'm > tired... :-0 > > Yes, I believe you have it wrong, take a look again above. Same applies to you... > > > (or the case where C is reachable) if D is supplied to > > > connect(). The current implementation sacrifices the cases > > > where D is not supplied to connect(). > > > > See above... > > > > > For applications that can have a knowledge of D (e.g. from > > > DNS lookup or static assignment) and requires a reliable > > > INIT process our current implementation is superior to > > > > Now that I think about it... I think this could be an > improvement for > > the INIT collision scenario... We could say that > instead of sending > > the INIT ACK to the destination address of the > previously sent INIT, > > we could use any of the "known addresses". The point is > that the RFC > > always considers that you only know one of the peer's > addresses... But > > this change would be completely equivalent and more > general. However, > > I don't know in how many places the RFC takes for > granted that while > > in the COOKIE WAIT state you know only one of the > peer's addresses... > > :-/ > > I don't see how this is so different from what our > implementation does. It But knowing the addresses before the peer tells you them is not a need... and most of the times it will be even impossible... > allows the ULP to provide a list of "known addresses" to the > connect(). This It seems that the connect() at the socket API for SCTP only takes one address. I don't follow this API so I do whatever I want. However, I think that it would be a good idea to modify it so instead of providing a sockaddr_in or sockaddr_in6 you can provide a list of them... Randall? (I doubt that other authors of the API draft are following this loooong thread) > allows the connection to be formed in both circumstances. It > then also > conforms to RFC 2960 behaviour (it sends the INIT-ACK to the > source of the > INIT). Also, it provide a list of addresses that SCTP can > try to send an INIT > to if the first INIT illicits no INIT-ACK (the case where C/D > is listening > but C is unreachable). > > If 2.6 permits me to send the INIT-ACK to any of these > "known" addresses, then > our implementation doesn't need to look in the source address > list in the > collision case because it can require the user to provide the > list of "known" > addresses and in fact does would not need to be changed to > comply with 2.6. > > --brian If you already know all the addresses of the peer you don't have any problem at all... But knowing all the addresses of the peer is not possible in all the situations... BR Iván Arias Rodríguez > > > > > IG 2.6. Where the application has no knowledge of D and > > > does not care about a reliable INIT process, 2.6 is superior > > > to our current implementation. > > > > See above... > > > > > Is this not a tradeoff that depends on the application? > > > > See above... > > > > BR Iván Arias Rodríguez > > > > > --brian > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > From owner-extdom.sctp-impl@sj-core-5.cisco.com Tue Mar 11 06:47:41 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16426 for ; Tue, 11 Mar 2003 06:47:37 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2BBi0hs003231 for ; Tue, 11 Mar 2003 03:44:01 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2BBhGQL018393 for ; Tue, 11 Mar 2003 03:43:17 -0800 (PST) Received: from gw.openss7.com (IDENT:zTJ9yiR4DF0Z2sDpA37G+djEct9B17M7@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h2BBg02W023702 for ; Tue, 11 Mar 2003 03:42:00 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:lIqm6RKVpcRjvuPM5B/PPXOGH2N0yRDh@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2BBd0D02916; Tue, 11 Mar 2003 04:39:00 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2BBcxg09782; Tue, 11 Mar 2003 04:38:59 -0700 Date: Tue, 11 Mar 2003 04:38:59 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: rrs@cisco.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030311043859.A8489@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Tue, Mar 11, 2003 at 12:00:02PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, Please read my first line: > > > > I don't know that I agree with 2.6 yet... 2.6 tells me I MUST send INIT-ACK to the same place as the INIT was sent regardless of which addresses were known in advance. My point was that by sending INIT-ACK to a known address our implementation was better than 2.6 on this point in that it provided reliable initialization. So, yes, please change 2.6 to say "known" address rather than the same place as the INIT was sent. And please define "known" address in the IG too. But I still have a problem considering the source address list when looking for the TCB on INIT as regards 2.6. Consider the following case: Host A INIT A:1000 -> C:1000 INIT X:1000 -> A:1000 (C) ----------------------\ /------------------ Host X \ / INIT A:1000 -> X:1000 \/ ----------------------\ /\ X \-------------------> Host C / \ / \ <-------------------/ \-------------------> Host X (1) Assume that Host A has no "known" addresses for either of its TCBs. At (1), where is the INIT-ACK sent? There are two TCBs in the COOKIE-WAIT state that match the addresses. INIT A:1000 -> C:1000 INIT D:1000 -> A:1000 (C) ----------------------\ /------------------ Host D \ / INIT A:1000 -> X:1000 \/ ----------------------\ /\ X \-------------------> Host C / \ / \ / \-------------------> Host X / INIT-ACK X:1000 -> A:1000 (C) <-----------------/--------------------------- Host X / <---------------/ (2) At (2), where is the INIT-ACK sent? There is one TCB in the COOKIE-WAIT state that matches address C in the INIT, and one TCB in the COOKIE-ECHOED state that matches C in the INIT, neither match D. INIT A:1000 -> C:1000 INIT D:1000 -> A:1000 (C) ----------------------\ /------------------ Host D \ / INIT A:1000 -> X:1000 \/ ----------------------\ /\ X \-------------------> Host C / \ / \ / \-------------------> Host X / INIT-ACK X:1000 -> A:1000 (C) <-----------------/--------------------------- Host X COOKIE-ECHO / ----------------/----------------------------> Host X / COOKIE-ACK <-------------/------------------------------- Host X / <-----------/ (3) At (3) there is one TCB in the COOKIE-WAIT state that matches address C in the INIT and on TCB in the COOKIE-ECHOED state that matches D in the INIT. What is done about the INIT-ACK? Is it discarded? Is it sent to C? Also consider n TCBs in various states, all that match the address various addresses in the INIT. What is done with the INIT-ACK in these cases of multiple matches? Also there is a vulnerability in the COOKIE-ECHO state in a separate mail. So, I don't know that I agree with 2.6. That is why I do not yet follow it. I believe that it places too heavy a reliance on a spoofable source address list in the INIT. I am not convinced that ever considering the spoofable source address list in an INIT or INIT-ACK is wise from the standpoint of security. Spoofing the source address list is the easiest way to dream up vulnerabilities in the INIT process. A procedure which thinks that one TCB will exist for a given source address list address has not considered source address list spoofing, and is likely insecure. See separate mail on COOKIE-ECHO state which exposes a new vunlerabilty for that state based on INIT-ACK source address list spoofing. --brian On Tue, 11 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > > Ivan.Arias-Rodriguez, > > > > On Mon, 10 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > > > Brian, > > > > > > > > > > > Ivan, > > > > > > > > I don't know that I agree with 2.6 yet... > > > > > > We finally agreed that the peer is not "able to > > establish associations in certain circumstances"... My mother > > tongue is not English, but I understood that from your "at > > very minor expense of this one unnecessary corner case [the > > INIT collision]" in one of your mails... > > > > > > > Consider your last case. If Interface C is unreachable > > > > from A, and following 2.6 and sending the INIT-ACK to C > > > > instead of D, the association will fail to form. > > > > > > > > INIT A:1000->C:1000 INIT D:1000->A:1000 > > > > ----------------------\ /----------------------- > > > > \ / > > > > \ / > > > > / \ > > > > / \ C unreachable > > > > <---------------------/ \--------------X > > > > > > > > INIT-ACK A:1000->C:1000 C unreachable > > > > ------------------------------------------>X > > > > > > > > > > And if C is unreachable, why including it in the INIT? > > Ok, let's say that SCTP doesn't know about the state of the > > interfaces... > > > > > > > Following RFC 2960, the association would form regardless > > > > of whether C was reachable from A. > > > > > > > > INIT A:1000->C:1000 INIT D:1000->A:1000 > > > > ----------------------\ /----------------------- > > > > \ / > > > > \ / > > > > / \ > > > > / \ C unreachable > > > > <---------------------/ \--------------X > > > > > > > > INIT-ACK A:1000->D:1000 > > > > ----------------------------------------------------> > > > > COOKIE-ECHO D:1000->A:1000 > > > > <---------------------------------------------------- > > > > COOKIE-ACK A:1000->D:1000 > > > > ----------------------------------------------------> > > > > > > > > Section 2.6 appears to sacrifice reliability in the INIT > > > > process by treating all interfaces except the interface > > > > that A has sent an INIT to as though they were an attacker. > > > > > > It seems that the case of INIT collision AND an > > unreachable (but still > > > included in the list of valid addresses) is more > > probable than the > > > case of INIT collision AND... nothing else... :-/ > > > > > > > Is it the intention of 2.6 to sacrifice this collision case > > > > if interface C is temporarily unreachable? > > > > > > Come on, Brian, you are sacrificing the other more > > general case... > > > your implementation works in this case, but not in the > > other, so? > > > > > > Or... let me see... hmmm... I *think* this is actually what your > > > implementation does (I might be wrong): > > > > Ivan, our implementation works in both cases if A supplies > > address C and D > > to the connect(). > > Of course!! > > And mine, and Randall's, and everybody's! > > This is NOT what we are discussing... You are saying that you don't have to take a look to the address parameters in ANY case... You fail to agree that knowing all the addresses beforehand is a need to avoid it... > > Of course I don't need to take a look to the address parameters in that case? Why? I already know what's inside! > > Brian, please, stop going around! I'm too tired of you saying something without proving anything, catching you and showing that what you were saying is not completely true and that it is based on some assumptions... and then you changing the topic again, and again, from one point of view to the opposite, and never admitting that *something* that you said might be wrong (I know your answer to this "I was never wrong")... > > So, as we were speaking about that case, DON'T CHANGE it again, please... > > This conversation is stupid... Of course if you know all the addresses since the beginning this case WON'T EVER happen. Please, Brian, stop changing your "problematic case" every time we find (or at least is seems so, we might be as well wrong) that such problematic case is not what seems to be, or that there is even a worse one that you didn't show... > > So, PLEASE, answer to what I write and don't change AGAIN the initial conditions... > > > > Host A > > Host C/D > > > > > > TCB \ INIT VT:0 IT:W INIT VT:0 > > IT:X / TCB > > > A:1000 \ A:1000->C:1000 > > D:1000->A:1000 / C,D:1000 > > > C:1000 \ > > / A:1000 > > > VTloc:W \ > > / VTloc:X > > > VTpeer:0 \ > > / VTpeer:0 > > > C-WAIT \ > > / C-WAIT > > > \--------------------\ /--------------------/ > > > > This is where the difference is, when (C,D) is supplied to > > connect() in > > our implementation, the TCB starts out as: > > Of course your implementation knows about the addresses... We have ALL this time saying that, of course, if you know the addresses in advance you don't need to take a look to them again... You don't even have to include them in the State Cookie... you already know them... you have already seen them... > > > > > Host A > > Host C/D > > > > TCB \ INIT VT:0 IT:W INIT VT:0 > > IT:X / TCB > > A:1000 \ A:1000->C:1000 > > D:1000->A:1000 / C,D:1000 > > C:1000,D:1000 > > / A:1000 > > VTloc:W \ > > / VTloc:X > > VTpeer:0 \ > > / VTpeer:0 > > C-WAIT \ > > / C-WAIT > > \--------------------\ /--------------------/ > > \/ > > /\ > > / \ > > (1) <-------------------------/ \-------------------------> X > > > > TCB is found (A:1000-D:1000) without looking at source > > address (D is already > > in the TCB as a "known address"). > > > > \ INIT ACK VT:X IT:W > > \ A:1000->D:1000 > > \ VTloc:W VTpeer:X > > \TTloc:0 TTpeer:0 > > \ > > \ > > \--------------------\ > > > > This INIT-ACK is completely compliant with RFC 2960. It > > includes the IT of > > the existing TCB and it is sent back to the source of the > > INIT. By telling > > SCTP that D is trustworthy, fully compliant RFC 2960 > > behaviour is accomplished > > without vulnerability. > > This is a DIFFERENT case to the one you initially proposed. Since you haven't found yet anything better to answer me, you just change the case... > > I have already seen that when you don't answer to something, it means that you admit that you might be wrong... Because, in any case, you basically never admit it... > > > > > \ > > \ > > \ > > \-------------------------> > > > > COOKIE ECHO > > VT:W / TCB > > > > D:1000->A:1000 / C,D:1000 > > VTloc:W > > VTpeer:X / A:1000 > > TTloc:0 > > TTpeer:0/ VTloc:X > > > > / VTpeer:W > > > > / C-ECHOED > > /--------------------/ > > / > > / > > / > > (2) <---------------------------/ > > \ > > \ VT matches, action B from Table 2 > > \ > > \ > > \ COOKIE-ACK > > \-----------------------------------------------------> > > > > > > At (1) your implementation as usual doesn't recognized > > the peer and > > > sends an INIT ACK with a new IT. > > > > When (C,D) are provided to connect(), the TCB is found as > > above and RFC 2960 > > compliant behavior is exhibited. > > My implementation is also able of doing so... and everybody's... The problem is that supplying all the addresses is not a MUST... > > > > > > > At (2), the VT doesn't help you to find any TCB. > > However, there is > > > already a conflicting TCB... I think there are two > > possibilities: > > > > When (C,D) is provided to connect(), there is only ever one TCB. > > Of course... > > > > > > > a) If you go through the address list inside the > > COOKIE, you will find > > > it, but, since none of the VT match and the Tie Tags > > are set to 0, you > > > discard it. Bad, the association doesn't come up... > > > > The TCB is found on address D because (C,D) was provided to connect(). > > It is unnecessary to use C from the source address list. > > > > > > > > b) You create a new TCB (and send back a COOKIE ACK not > > included in > > > > Not, when (C,D) is provide to connect(). Look more closely > > at the above. > > Look more closely to your initial words and don't change them now... Brian, why being and engineer when you could be a politician? :-) > > > > the drawing), and then you take a look to the other > > existing TCBs (you > > > must do this, otherwise you take the risk of having two > > conflicting > > > established associations) and you see one in conflict. > > So, you happily > > > decide that this new TCB "includes" the old one, and > > you tell to the > > > upper user that its association with C is established. > > Everything > > > looks perfect. However, so far Host C/D has not proven > > at all that it > > > owns address C. Conclusion? Much worse. Host A thinks that it is > > > speaking with C, while he could be speaking with an > > attacker that > > > simply included address C in the list. This possibility > > needs: 1) > > > either the adapter C is broken or at least the INIT > > from Host A is > > > delayed enough time, 2) the attacker knows you are > > about to connect > > > with C. > > > > > You have insisted that these scenario is possible (and > > even more, you > > > were scared about the possibility of not only all this > > happening, but > > > also trying to connect with the "real" C and with the > > attacker, D, at > > > about the same time). I hope you don't say now that > > this is an extreme > > > corner case, since yours was even more weird. > > > > I agree that being unable to form a connection when an > > inteface is unavailable > > is more rare than the collision case. But Randall told me > > that the collision > > case was common. Which is it? I think that the probability > > He didn't say it was common... At least what I understood was that it wasn't uncommon, which doesn't mean the same as far as I know... > > Saying that there is a case where it used to happen, doesn't mean that it is common... > > But again, you are changing words... :-/ > > > of any vulnerability > > case is dependent upon the application and what the attacker > > does. Otherwise > > why would we spend so much time talking about corner cases? > > That's precisely what I think... Just state that iff you provide the list of addresses you don't need to inspect the address list... otherwise... it is your own risk... it may work most of the times... but it may not work sometimes... > > > Besides, mission critical applications that have a high cost > > associated > > with failing to make connections and require 5 or 6 nines of > > availability > > cannot afford to have the INIT process fail because one interface is > > temporarily unreachable. Our implementation is indeed > > intended to work in > > these environments. It appears that 2.6 is not. > > Your application works? > > Please, tell me how it does so, WITHOUT knowing in advance the list of addresses... This is what you shown... You show the case, you say your implementation is better, and everybody claps... What you didn't say is that your implementation is better IFF you have MORE information than the other implementation... Of course then it is better... of course! > > > > So, which option does your implementation choose, the > > bad or the worse? > > > > In our implementation, the cost of forming the connection in > > all circumstances > > is having the ULP supply the list of "known addresses" to the > > connect() command. > > So? > > Either you look at the address list or you know the addresses... But since you CANNOT know the addresses in advance in all the circumstances, you have to take a look to the addresses... > > The point of all this discussion is that you have to know all the addresses of the peer when you receive the INIT to be able to act consistently. You knew them before? Ok, don't look at them again, they are the same ones... > > > > > Our current implementation does not sacrifice this case > > > > > > As I think, it sacrifices both, or it is open to > > attacks... As I said > > > above, I might be wrong as well... it is late and I'm > > tired... :-0 > > > > Yes, I believe you have it wrong, take a look again above. > > Same applies to you... > > > > > (or the case where C is reachable) if D is supplied to > > > > connect(). The current implementation sacrifices the cases > > > > where D is not supplied to connect(). > > > > > > See above... > > > > > > > For applications that can have a knowledge of D (e.g. from > > > > DNS lookup or static assignment) and requires a reliable > > > > INIT process our current implementation is superior to > > > > > > Now that I think about it... I think this could be an > > improvement for > > > the INIT collision scenario... We could say that > > instead of sending > > > the INIT ACK to the destination address of the > > previously sent INIT, > > > we could use any of the "known addresses". The point is > > that the RFC > > > always considers that you only know one of the peer's > > addresses... But > > > this change would be completely equivalent and more > > general. However, > > > I don't know in how many places the RFC takes for > > granted that while > > > in the COOKIE WAIT state you know only one of the > > peer's addresses... > > > :-/ > > > > I don't see how this is so different from what our > > implementation does. It > > But knowing the addresses before the peer tells you them is not a need... and most of the times it will be even impossible... > > > allows the ULP to provide a list of "known addresses" to the > > connect(). This > > It seems that the connect() at the socket API for SCTP only takes one address. I don't follow this API so I do whatever I want. However, I think that it would be a good idea to modify it so instead of providing a sockaddr_in or sockaddr_in6 you can provide a list of them... > > Randall? (I doubt that other authors of the API draft are following this loooong thread) > > > allows the connection to be formed in both circumstances. It > > then also > > conforms to RFC 2960 behaviour (it sends the INIT-ACK to the > > source of the > > INIT). Also, it provide a list of addresses that SCTP can > > try to send an INIT > > to if the first INIT illicits no INIT-ACK (the case where C/D > > is listening > > but C is unreachable). > > > > If 2.6 permits me to send the INIT-ACK to any of these > > "known" addresses, then > > our implementation doesn't need to look in the source address > > list in the > > collision case because it can require the user to provide the > > list of "known" > > addresses and in fact does would not need to be changed to > > comply with 2.6. > > > > --brian > > If you already know all the addresses of the peer you don't have any problem at all... But knowing all the addresses of the peer is not possible in all the situations... > > BR Iván Arias Rodríguez > > > > > > > > IG 2.6. Where the application has no knowledge of D and > > > > does not care about a reliable INIT process, 2.6 is superior > > > > to our current implementation. > > > > > > See above... > > > > > > > Is this not a tradeoff that depends on the application? > > > > > > See above... > > > > > > BR Iván Arias Rodríguez > > > > > > > --brian > > > > -- > > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > > ¦ Therefore all progress depends on the ¦ > > ¦ unreasonable man. -- George Bernard Shaw ¦ > > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-2.cisco.com Tue Mar 11 07:11:04 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16991 for ; Tue, 11 Mar 2003 07:11:02 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2BBvhEY028425 for ; Tue, 11 Mar 2003 03:57:44 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2BBv0US025363 for ; Tue, 11 Mar 2003 03:57:00 -0800 (PST) Received: from gw.openss7.com (IDENT:I7wnYjJIIHd+qwIgI8jAfCuaP7pOqRzU@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2BBvfof019518 for ; Tue, 11 Mar 2003 03:57:46 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:5ECS4nKk4/aaJ5Ppzvs8JsgnG+NVi4/b@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2BBo2D03071; Tue, 11 Mar 2003 04:50:02 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2BBo1R09992; Tue, 11 Mar 2003 04:50:01 -0700 Date: Tue, 11 Mar 2003 04:50:00 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: rrs@cisco.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030311045000.B8489@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Tue, Mar 11, 2003 at 12:00:02PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan, Randall, Here is a new source address spoof (DoS and hijack) attack on the COOKIE-ECHOED state. 2.6 does not have this correct yet (and neither does the RFC). IG Section 2.6 Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiation Tag, unchanged) provided that no NEW address have been added to the forming association. If the INIT message indicates that a new address(es) have been added to the association, then the entire INIT MUST be discarded and NO changes should be made to the existing association. An ABORT MUST be sent in response that SHOULD include the error 'Restart of an association with new addresses'. The error SHOULD list the addresses that were added to the restarting association. Host A/B Host X Host C/D | | | |INIT A:1000 -> X:1000 | | |---------------------------------------------->| | |TCB1: | | |VT: X | | |PT: 0 | | |Loc: A:1000 | | |Rem: X:1000 | | |State: COOKIE-WAIT | | | | | | INIT-ACK X:1000 -> A:1000 (D)| | |<----------------------------------------------| | |(TCB1 is found) | | | | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | |TCB1: | | |VT: X | | |PT: W | | |Loc: A:1000 | | |Rem: X:1000, D:1000 | | |State: COOKIE-ECHOED | | | X does not | | | send (or delays) | | COOKIE-ACK | | | | | |T1-cookie timeout | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | | | | |T1-cookie timeout | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | Note that X can keep the T1-cookie timeout initially high by responding to a retransmitted INIT instead of the first INIT above. T1-cookies doubles with each retransmission up to 60 seconds, so the sequence is 3sec, 6sec, 12sec, 24sec, 48sec, 60sec, 60sec, 60sec which is 273 seconds or about 4 minutes. There are ways to extend this period longer. | | | | INIT C:1000 -> A:1000 (D)| |<-------------------------------------------------------| | | | |ABORT ERROR (Restart with new addresses) | | |------------------------------------------------------->| | | | |T1-cookie timeout | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | | . | | | . | | | . | | | | | Following IG Section 2.6 provides for DoS attack with spoofed addresses in address list. Host X can refuse access to A for an arbitrary number of multi-homed hosts, should A form an association with X. Here is a reverse hijack: Host A/B Host X Host C | | | |INIT A:1000 -> X:1000 | | |---------------------------------------------->| | |TCB1: | | |VT: X | | |PT: 0 | | |Loc: A:1000 | | |Rem: X:1000 | | |State: COOKIE-WAIT | | | | | | INIT-ACK X:1000 -> A:1000 (C)| | |<----------------------------------------------| | |(TCB1 is found) | | | | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | |TCB1: | | |VT: X | | |PT: W | | |Loc: A:1000 | | |Rem: X:1000, C:1000 | | |State: COOKIE-ECHOED | | | X does not | | | send (or delays) | | COOKIE-ACK | | | | | |T1-cookie timeout | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | | | | |T1-cookie timeout | | |COOKIE-ECHO A:1000->X:1000 | | |---------------------------------------------->| | | . | | | . | | | . | | | | | | INIT (IT: Y) C:1000 -> A:1000| |<-------------------------------------------------------| | | | |INIT-ACK (IT: X, no tie tags) | | |------------------------------------------------------->| | | | | COOKIE-ECHO C:1000 -> A:1000 | |<-------------------------------------------------------| |Action B | | |COOKIE-ACK A:1000 -> C:1000 | | |------------------------------------------------------->| |TCB1 | | |VT: X | | |PT: Y | | |Loc: A:1000 | | |Rem: X:1000, C:1000 | | |State: ESTABLISHED | | X now knows A's verification tag for its association with C. X can know that the association is established with C because COOKIE-ECHOs stop prematurely, or if A does not kick X out of the TCB (not stated in RFC or IG), a DATA or HEARTBEAT will eventually tell X that it is in the established state. DATA or a HEARTBEAT would also tell X C's verification tag for the association. Or, if X is not kicked out of the TCB, it could send an INIT and read C's verification tag out of the tie tags in the cookie in the INIT-ACK. If X is not kicked out of the TCB then one-way eavesdropping is possible. | | | |DATA (VT: Y) | | |---------------------------------------------->|------->| | | | Even if X is kicked out of the TCB, X knows A's verification tag for the association between A and C. A simultaneous attack on C could yeild C's verification tag for the association. A DoS attack would be to send an ABORT to A with the known VT when the COOKE-ECHO is not received, and start the process again with a new INIT. This DoS attack has the difference over the previous one that no ERROR message is sent to C. To avoid this problem, INIT received in the COOKIE-ECHO state needs to be treated the same as INIT in the ESTABLISHED state (new verification tag chosen), or COOKIE-WAIT (sent to X or known address of X). The former is preferrable because it does not cause a new denial of service attack. Closing this latter vulnerability also removes the need to find the existing TCB in the COOKIE-ECHO state based on the source address list, because a new IT is generated and no tie tags populated. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Tue Mar 11 07:46:02 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17629 for ; Tue, 11 Mar 2003 07:45:58 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2BCcd0E002282; Tue, 11 Mar 2003 04:38:39 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEJ63730; Tue, 11 Mar 2003 04:38:36 -0800 (PST) Message-ID: <3E6DD8CC.6070007@cisco.com> Date: Tue, 11 Mar 2003 06:38:36 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Caitlin Bestler , sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030303103316.B15597@openss7.org> <20030308025453.A26345@openss7.org> <3E69DE4D.8010609@cisco.com> <20030309153850.B25482@openss7.org> <3E6C92B1.2070607@cisco.com> <20030310203402.B1806@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > ok, now we change sides again? > > >>3) Look at the state of the existing one, if still forming >> let the cookie-echo go out, but instead mark each >> as suspect and needing HB before letting either >> proceed to ESTABLISHED... if you will put a >> delayed for security reasons... kind of like going >> to an airport but not randomly being singled out >> .. instead being singled out due to a problem. Then >> when the COOKIE-ACK arrives back from each >> you can HB each address before proceeding and >> thus find out who is who ... >> >> > >But then you are sending the "extra" COOKIE-ECHO and the >entire determination can be made at receipt of COOKIE-ACK >(different source address lists) and there is no need to >look in the source address list of the INIT or INIT-ACK. > > No, you missed my point.. you LOOK in the INIT-ACK and FIND the other association... ONLY in this case do you send the Heartbeat.. this way you ONLY send the "extra" cookie if you get the very scenario you painted. If the peer gives you completely overlapping addresses (the legit collision case) you do as you are supposed to and use the tag that you sent in the INIT... something your implementation can not do... This way it is only in this little corner case that one needs to do anything... And your argument about which addresses to heartbeat assuming the evil guy supplied you with a large list of "bogus" addresses.. well you would HB only the over-lapping ones first.. since these would be standing out as possible incorrect addresses... so guess what first HB will be valid or return an ABORT.. And as to your why a web server would do this.. if a proxy is worried about displaying adds of the competition why even show them in the first place.. if it is that sophisticated that it can play in the kernel.. it is far easier to filter the web sites and other addresses of the competitors at the app level... and more effective as well.. > > >>> | | | >>> |T1-cookie timeout | | >>> |COOKIE-ECHO A:1000->X:1000 | | >>> |---------------------------------------------->| | >>> | | | >>> |T1-cookie timeout | | >>> |COOKIE-ECHO A:1000->X:1000 | | >>> |---------------------------------------------->| | >>> | . | | >>> | . repeat | | >>> | . | | >>> >>>Note that X can find the address to include in its INIT merely >>>by sending an INIT to C or D and getting an INIT-ACK. >>> >>> >>> >>> >>> >>And then guessing who is going to contact me at the same >>exact time that it is contacting C or D... >> >> > >X does not need to guess who is going to contact it. It can >attack every host that contacts it. > > But only if X can guess which host the client will contact next... Your http issue does not hold water... and a simple HB to the conflicting addresses will quickly prove X to be a problem... > > >> >> >>>If the INIT-ACK is not refused, and a COOKIE-ECHO is returned >>>(the "extra" packet), the following occurs: >>> >>> >>>Host A/B Host X Host C/D >>> | | | >>> |INIT A:1000->X:1000 | | >>> |---------------------------------------------->| | >>> |TCB1: | | >>> |VT: X | | >>> |PT: 0 | | >>> |Loc: A:1000 | | >>> |Rem: X:1000 | | >>> |State: COOKIE-WAIT | | >>> | | | >>> |INIT A:1000->C:1000 | | >>> |------------------------------------------------------->| >>> |TCB2: | | >>> |VT: Y | | >>> |PT: 0 | | >>> |Loc: A:1000 | | >>> |Rem: C:1000 | | >>> |State: COOKIE-WAIT | | >>> | | | >>> | INIT-ACK X:1000->A:1000 (D)| | >>> |<----------------------------------------------| | >>> |(TCB2 cannot be found on source addr list) | | >>> |(TCB1 is found) | | >>> | | | >>> |COOKIE-ECHO A:1000->X:1000 | | >>> |---------------------------------------------->| | >>> |TCB1: X does not | | >>> |VT: X send (or delays) | >>> |PT: W COOKIE-ACK | | >>> |Loc: A:1000 | | >>> |Rem: X:1000, D:1000 | | >>> |State: COOKIE-ECHOED | | >>> | INIT-ACK C:1000->A:1000 (D)| >>> |<-------------------------------------------------------| >>> | | | >>> |COOKIE-ECHO A:1000->C:1000 | | >>> |------------------------------------------------------->| >>> |TCB2: | | >>> |VT: X | | >>> |PT: Z | | >>> |Loc: A:1000 | | >>> |Rem: C:1000, D:1000 | | >>> |State: COOKIE-ECHOED | | >>> | COOKIE-ACK C:1000->A:1000| >>> |<-------------------------------------------------------| >>> |TCB2: | | >>> |VT: X | | >>> |PT: Z | | >>> |Loc: A:1000 | | >>> |Rem: C:1000, D:1000 | | >>> |State: ESTABLISHED | | >>> | | | >>> |(Discard TCB1, inform user) (attacker thwarted)| | >>> | | | >>> >>>What this would do is force attacker X to reply quickly with >>>a COOKIE-ACK in order to block the legitimate host as in: >>> >>> >>> >>But how do you still know which is the hacker and which >>is the legit server is it X/D or C/D? In this case you >>are saying its whoever gets a COOKIE-ACK to me >>first... this is not good.. since you can't tie the two associations >>(by your refusal to look in the INIT/INIT-ACK) you can't >>do anything but hope that the real user is faster or closer... >>Instead one can do as I state above in <3> hmm I think >>I will look into getting this coded into the BSD implementation >>seems like a good general solution to the issue... >> >> > >Looking at the sources address list and finding the other TCB >does nothing to help with the situation. You still do not know >which is the attacker and which is the legitimate host. The >ordering of the messages is unimportant. > > Yes it does since you then can find that the conflict exists.. besides it does allow one to follow RFC2960 and use the same tag when you get the true colliding INIT case ... >One can only mark them both as suspect. But as noting can be >done until after receiving COOKIE-ACK for both, and because the >determination of suspect TCB can be made at that time, it is not >necessary to consider the source address list on INIT or >INIT-ACK, the determination can be deferred to when the second >COOKIE-ACK is sent attempting to establish two associations with >overlapping addresses. > > But you can't reuse the correct I-Tag per RFC2960 without looking at the INIT's address list... >In the case that there is no malicious endpoint, only one >COOKIE-ACK will be returned, and there is no need to mark TCBs >suspect. If the second COOKIE-ACK is returned attempting to >move the overlapping TCB to the ESTABLISHED state. > >HEARTBEAT cannot be used as you suppose, because both TCBs >cannot be moved to the ESTABLISHED state (no two associations to >an overlapping set of trasnport address combinations). > > Take a closer look at the IG.. the peer WILL respond to a HB since it sent the COOKIE-ACK it is in ESTABLISHED and is assured of response.. Yes we may need to add another exception.. but I won't go down that path unless Steve thinks that this case is worth being concerned about... which quite frankly.. based on some of my other conversations with him.. I don't think he will be... >When the first COOKIE-ACK is accepted, the TCB must move the the >established state, making it impossible for the second to move >to the established state. It is still a race between the >attacker and the legtimate user on the COOKIE-ACK. > > But using HB's it is no longer a race... sorry if this situation is worth considering I would rather instead of having a race have a assured mechanism to deal with it... >One could HEARTBEAT the association immediately after receiving >COOKIE-ACK, but the attacker can give an arbitrarily long list >with "bogus" addresses that will pass the HEARTBEAT. RFC 2960 >also does not permit more than one HEARTBEAT per heartbeat >interval (and rightfully so). If many destinations where sent a >HEARTBEAT immediately there would be a packet multiplication and >the attacker would have another DoS attack by making A send out >more than one HEARTBEAT for each message in the exchange. > > But you KNOW up front which addresses are suspect.. the ones that collide with the other association... so it is quite easy to HB just the correct address.. no matter if the peer gives you 1000 bogus addresses.. you can quickly know which one is the overlapping one... >Nevertheless sending the COOKIE-ECHO in this case limits the >attack (the COOKIE-ECHO timeout sequence is not possible), so >I don't see that this is an "extra" COOKIE-ECHO as its purpose >is to limit a vulnerability. > > And leaves things completely up to a "race" which is not a solution.. > > >>>Host A/B Host X Host C/D >>> | | | >>> |INIT A:1000->X:1000 | | >>> |---------------------------------------------->| | >>> |TCB1: | | >>> |VT: X | | >>> |PT: 0 | | >>> |Loc: A:1000 | | >>> |Rem: X:1000 | | >>> |State: COOKIE-WAIT | | >>> | | | >>> |INIT A:1000->C:1000 | | >>> |------------------------------------------------------->| >>> |TCB2: | | >>> |VT: Y | | >>> |PT: 0 | | >>> |Loc: A:1000 | | >>> |Rem: C:1000 | | >>> |State: COOKIE-WAIT | | >>> | | | >>> | INIT-ACK X:1000->A:1000 (D)| | >>> |<----------------------------------------------| | >>> |(TCB2 cannot be found on source addr list) | | >>> |(TCB1 is found) | | >>> | | | >>> |COOKIE-ECHO A:1000->X:1000 | | >>> |---------------------------------------------->| | >>> |TCB1: | | >>> |VT: X | | >>> |PT: W | | >>> |Loc: A:1000 | | >>> |Rem: X:1000, D:1000 | | >>> |State: COOKIE-ECHOED | | >>> | INIT-ACK C:1000->A:1000 (D)| >>> |<-------------------------------------------------------| >>> | | | >>> | COOKIE-ACK X:1000->A:1000| | >>> |<----------------------------------------------| | >>> |TCB1: | | >>> |VT: X | | >>> |PT: W | | >>> |Loc: A:1000 | | >>> |Rem: X:1000, D:1000 | | >>> |State: ESTABLISHED | | >>> | | | >>> |(Discard TCB2, inform user) | | >>> | | | >>> >>>What this serves to do is put the attacker immediately into the >>>ESTABLISHED state. If the attacker delays the COOKIE-ACK, the >>>the legitimate peer will win the race and the attack is >>>thwarted. The attacker cannot block for the initial 4 minutes, >>>but can still place bogus addresses in the address list that >>>will extend the period of time before a HEARTBEAT/ABORT sequence >>>to D takes the association down. >>> >>> >>> >>And <3> above will avoid even this... >> >> >> >>>The major difference is that, in the ESTABLISHED state, the >>>user of TCB1 can challenge the peer. In the COOKIE-ECHOED >>>state, the user of TCB1 is blocked from communicating on the >>>association and the ULP cannot assist in detecting the attack. >>> >>>Because X and D are indistinguishable to "A" ("A" has no prior >>>knowledge of D or X), the only way to limit the attack is by >>>sending the "extra" COOKIE-ECHO. So for the sake of security in >>>this case, whether it be rare or not, it is better to send the >>>extra COOKIE-ECHO than not. >>> >>> >>> >>Yes I see the point of the "extra" COOKIE-ECHO... in this one corner >>case where you have non-completely overlapping INIT-ACK's aka >>one is saying (X/D) the other (C/D).. Caitlins example was one where >>you had the same overlap.. (C/D) and (C/D) in the INIT's.. using >><3> , one could easily tell if the two INIT-ACK's were completely >>overlapping or partially overlapping ... this way the legitimate case >>would NOT generate the extra COOKIE-ECHO and the "evil >>server" case would so that one could proceed carefully and select >>the correct address set for the peer... I.e. which is the evil >>attacker X/D or C/D.... This is a interesting case and I do think >>I will put it on my discussion list with Steve... if I can get some >>of his time... I am not sure if it warrents writting the code to >>handle it.. I will ask him before I get to deep into coding <3> :-0 >> >> > >Good, I think you follow me now. > > >In our implementation where the first connect() has addresses >(C,D) and the second has address (X), the attacker can always be >identified and thwarted. > >Also, the implementation is not required to allow users to >launch two inits in this fashion. (For example, I could delay >sending the second INIT until there is no TCB in a state other >than CLOSED or ESTABLISHED for the same local address and port >pair. Then neither situation can occur, and there is no extra >COOKIE-ECHO and no vulnerability. > The nano-second you send the INIT, you can get back an INIT from the very peer you just sent to.. using one of his alternate addresses as the source.. you are required by RFC2960 to use the same tag and send back the INIT-ACK... You need to look at the address list to do this... so yes there is a need to look at the INIT/INIT-ACK address list... > >This would, of course, mean that there was no need for me to >look in the source address list of the INIT or INIT-ACK. > > >>>Taking actions on unverifiable addresses in the source address >>>list of INIT-ACKs is IMO quite naive. It opens the protocol up >>>to an entire spectrum of addresss spoofing attacks. The only >>>source address that is verified in INIT and INIT-ACK are the >>>packet header source addresses. (The INIT packet source addres >>>is verified by HMAC on COOKIE-ECHO; the INIT-ACK source address >>>is verified by port pair, destination address and VT of the >>>INIT-ACK matching those of the INIT.) >>> >>>The reason that 2.6 in the COOKIE-WAIT state works for collision >>>is because the INIT-ACK with the existing VT is sent to the same >>>address as the INIT. The receiver of the INIT already has the >>>VT from the INIT so sending it in the INIT-ACK to same address >>>does not expose the VT. >>> >>>In ths case, it is not possible for "A" to determine whether D >>>truly belongs to X or whether it truly belongs to C without >>>prior knowledge of address D. In the case where knowledge of >>>address D can be easily obtained (e.g. DNS query), "A" is even >>>the more vulnerable to X if it does not utilize the same >>>readily available information about D. >>> >>>This is really scary. Server X can easily discover the secondary >>>addresses service to which it wishes to block access by launching >>>INITs to them and getting INIT-ACKs. Then server X can place >>>_all_ the secondardy addresses in the address list (say 200 of >>>them). >>> >>> >>> >>I have so far, not stumbled upon any such web servers.. aka that are >>hackers that try to block other sites from being hit... Steve may know >>a bit more.. I don't as yet believe this is that scary of a problem... >>And if it is, the steps in <3> above can be used to correct it.. >> >> > >This is because TCP does not have the vulnerability because it >does not naively consider an source address list. Such servers >running SCTP will be vulnerable. > > Like I said, we will see if Steve thinks it is an issue.. if so the HB scenario fixes the problem and eliminates a "horse race" that is not a solution... > > >>I think a far more likely DOS attack would be when X gets a >>INIT from A it then starts sending ton's of INIT's to A until >>it finds a open port.. then it can generate lots and lots and lots >>of INIT's from bogus addresses that nicely get you to do >>the HMAC algorithms.. I would be much more concerned about >>that aspect than this one .. but like I said Steve may have a different >>perspective.... if so I will code up <3> for our implementation... >> >> > >The rate of INIT-ACKs sent to a given destination (the source >address in the INIT packet, whether spoofed or not) can easily >be measured and throttled and alarms generated. Nevertheless >a system can be design so that all an attacker can do is "delay" >the INIT process of legitimate assocations, not deny them. > > It is still a much easier attack to launch and it can effect any endpoint.. not just those that happen to be connecting to you and wish to connect to some else that you predict :-0 > > >>>The one way that I can see to block the attack is by not >>>permitting sockets bound to a static port address with >>>SO_REUSEADDR to have their TCBs expanded by the INIT-ACK beyond >>>the addresses that were supplied to connect() iff any other TCB >>>is bound to the same static address (i.e., if resuse is actually >>>in effect, for our imp that means if the bind bucket is not >>>marked for fastreuse). Then the attack cannot form, and neither >>>association will form unless sufficient prior knowledge was >>>supplied to at least one of the two connect()s. This is >>>certainly not too strong a restriction to place on socket users. >>> >>> >>> >>> >>I see no reason for this restriction.. >> >> > >I don't either now. As I say above, the whole situation could >be avoided by delaying sending the second INIT until the first >association enters the CLOSED or ESTABLISHED state. There is >no requirement in the RFC or IG that tells me when an implementation >must send an INIT, so I can avoid the situation as I like. > > Like I said, the minute you launch an INIT you can get the collision scenario.. ahh.. I see you are not attempting to get around your collision scenaro/ violation of the current MUST in RFC2960.. but instead just this one attack.. That will work but you are doing a trade off .. if I am an evil attacker "passive/aggressive" server I can delay sending the INIT-ACK until the last possible retran (has you previously mentioned)... then I can do the same thing with the cookie ack.. So in the case of a default parmeters case.. I can hold you up for roughly 16 retransmissions.. blocking your stack from all outgoing connections during that time... lets see.. (3 + 6 + 12 + 24 + 48 + 60 + 60) * 2 = 426 seconds.. So you can be held for over 7 minutes every time you contact a "passive/aggressive" server. Seems like another attack to me... I think the HB of the collided addresses (suitably apart of course) would be a better approach.. and solve the problem without blocking your stack from sending INIT's to legit users... > > >>>This also means that the "extra" COOKIE-ECHO would never occur >>>because the INIT-ACK can be refused on the basis of the bind >>>characteristics. >>> >>>I still don't need to examine the address list when searching >>>for a matching TCB, because any action taken on the address list >>>is vulnerable to attack. The address list has not been >>>verified. >>> >>>The only use for the packet source address in the INIT is to >>>know where to send (in the collision corner case) the INIT-ACK, >>>and to populate the cookie. >>> >>> >>> >>> >>Far more likely of a corner case than your evil attacker server >>(sort of passive agressive actually :>).... >> >> >> >>>The only use for the packet source address and source address >>>list in the INIT-ACK is to expand unexpanded TCBs. (In this >>>case, if sufficient address information is not supplied I will >>>refuse to expand the TCB.) >>> >>>I hope this illustrates why it is unecessary (and is a secuirty >>>risk) to examine the source address list of INIT-ACK. >>> >>> >>> >>> > >[snip] > > > >>A simple 'un-trusted' flag could be added to the socket-api to allow one >>to declare.. I don't trust this peer HB every address before we converse.. >> >> > >Waiting to HB every address would still deny service for the >period of time it takes to HB. > > Ahh, but one only needs to HB the collided addresses.. I don't need to HB non-overlapping addresses.. once all the collided addresses are HB'd the impostor will have been found... > > > >>Not counting the corner case you illustrate above which I laid out >>a solution that will immediately bring the bogus peer into suspect >>even without a 'un-trusted' flag. >> >>One other thing I want to note... before I read your 2.6 issues.. >> >>5.2.1 of RFC2960 states: >> >>"5.2.1 INIT received in COOKIE-WAIT or COOKIE-ECHOED State (Item B) >> >> This usually indicates an initialization collision, i.e., each >> endpoint is attempting, at about the same time, to establish an >> association with the other endpoint. >> >> Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an >> endpoint MUST respond with an INIT ACK using the same parameters it >> >> >> >>Stewart, et al. Standards Track [Page 60] >> >>RFC 2960 Stream Control Transmission Protocol October 2000 >> >> >> sent in its original INIT chunk (including its Initiation Tag, >> unchanged). These original parameters are combined with those from >> the newly received INIT chunk. The endpoint shall also generate a >> State Cookie with the INIT ACK. The endpoint uses the parameters >> sent in its INIT to calculate the State Cookie. >>" >> >>Note the 'MUST respond with an INIT ACK using the same parameters it >>sent in it soriginal INIT chunk (including its Initiation Tag," >> >>Your implementation, at least from your conversations in this >>thread, does NOT do this... (in the double multi-homed case aka >>the colliding INIT's that Ivan painted) >> >> > >No it doesn't because to do so for an untrusted address (when D >is not provided to connect()) would hand the verification tag in >the initiate tag to the attacker. > >When D is provided to connect (as a known and trusted address), >I following this. > >This is what 2.6 was intended to fix. The 2.6 fix, however, >causes association initializations to be unreliable and I think >that there is yet another attack on 2.6 (because 2.6 does not >stop the implementation from taking action on untrusted >addresses from the souce address list). The only way that I see >to close all the attacks is to not trust the source address list >and take no action on it. This is what I have done from the >start, ignored the source address list and provided a way for >the user to provide a list of known and trusted addresses to >connect(). > > Nope.. I disagree.. assocaition initiation is no more un-reliable than sending a INIT to a single address... no difference... and as far as that goes if you want to discuss un-reliable association setup, I think Ivan as illustrated to you this very case where you do NOT setup the assocaition.. all it takes is the peer to send its INIT from an alternate address (from which you used to send the INIT) and you can't bring up the association.. with default routing this is a far worse case.. since your scenario requires something to be unreachable/broken where Ivan's scenario has everything reachable and available and you won't bring up an association.. This is far more unreliable in my opinion.. but thats another thread.. the other side of your argument. R >I'll work up a DoS attack for 2.6 collision case for you in a >separate mail. It should be easy. I will just replace C with >the attacker (the place to which the INIT-ACK will be sent). > The very place you sent your first INIT? again contacting an attacker? >Then X will forward the INIT-ACK to the legitimate host spoofed >from A and X will have hijacked at least part of the >association. > > A man-in-the-middle attack, where the routing infrastructure has been compromised breaks all security unless you have end2end encryption aka IPSEC.. R >--brian > > > > >>R >> >> >> >> >> >>>I will talk to the "new addresses" of section 2.6 in a separate >>>mail. (This one is already way too long ;) >>> >>>--brian >>> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Tue Mar 11 08:10:13 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18289 for ; Tue, 11 Mar 2003 08:10:11 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2BCxd0E015046 for ; Tue, 11 Mar 2003 04:59:41 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2BCwuxN026290 for ; Tue, 11 Mar 2003 04:58:56 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2BCxi7f009823 for ; Tue, 11 Mar 2003 04:59:48 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BClhF22785 for ; Tue, 11 Mar 2003 14:47:43 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 14:44:15 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 14:44:15 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 14:44:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Tue, 11 Mar 2003 14:44:13 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLnw5hWdpf5lFOzRWyJ/5VhP/i7YAAAZovQ From: To: Cc: , , X-OriginalArrivalTime: 11 Mar 2003 12:44:14.0857 (UTC) FILETIME=[EC4BE790:01C2E7CB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA18289 Brian, > > Ivan.Arias-Rodriguez, > > Please read my first line: > > > > > > I don't know that I agree with 2.6 yet... > > 2.6 tells me I MUST send INIT-ACK to the same place as the > INIT was sent regardless of which addresses were known in > advance. That's simply not true. It doesn't say anything about "regardless of which addresses were known in advance" and it fact yesterday I proposed (and Randall agreed) that instead of sending the INIT ACK to the same destination as the INIT, we could do it to any of the "known" addresses... However, you just like to argue... Seems like you don't really want to fix or improve anything... Otherwise you would have made constructive comments... proposals... > My point was that by sending INIT-ACK to a known address > our implementation was better than 2.6 on this point in that > it provided reliable initialization. Your point doesn't have any value, since you are playing with marked cards. You say "my implementation is better because it does this better", but you don't say that to be able to do so you need extra information. Give that extra information to my implementation and let's see how it solves the problem as nicely as yours. But, don't give us that information (which is very likely to be impossible to retrieve) and let's see which one is better... > So, yes, please change 2.6 to say "known" address rather > than the same place as the INIT was sent. And please define > "known" address in the IG too. As I told you, yesterday we were proposing something like that... You are also most welcome to propose any text for this change... > But I still have a problem considering the source address > list when looking for the TCB on INIT as regards 2.6. > > Consider the following case: > > Host A > > INIT A:1000 -> C:1000 INIT X:1000 -> A:1000 (C) > ----------------------\ /------------------ Host X > \ / > INIT A:1000 -> X:1000 \/ > ----------------------\ /\ > X \-------------------> Host C > / \ > / \ > <-------------------/ \-------------------> Host X > (1) > > > Assume that Host A has no "known" addresses for either of > its TCBs. At (1), where is the INIT-ACK sent? There are > two TCBs in the COOKIE-WAIT state that match the addresses. I quote from one of Randall's last mails answering to a mine one: ---------------------------------- > And, I haven't thought about this, but, what would happen if the address list in the INIT contains addresses of *more than one* other association? This would clearly identify the INIT as coming from an attacker... :-/ > > Yes, this is a good point.. one could use this type of information to determine an attacker and I would expect log this somewhere a counter or something.... but one must be careful about logging since this to can be an attack :-0 ---------------------------------- However this case is different, since you don't really have two associations... Actually it is only one. At the COOKIE WAIT state you don't normally know all the addresses of the peer (no matter what you say). I guess that in this case, since the INIT comes from X, you should answer back to X "from" the second TCB (the one that includes X). You would copy its IT and stuff... I don't feel like thinking what would happen at the end, but I suppose that once you have the COOKIE ECHO, you should join both associations into a single one... Do you propose anything different? What I have said is just what I think about right now... > > INIT A:1000 -> C:1000 INIT D:1000 -> A:1000 (C) > ----------------------\ /------------------ Host D > \ / > INIT A:1000 -> X:1000 \/ > ----------------------\ /\ > X \-------------------> Host C > / \ > / \ > / \-------------------> Host X > / INIT-ACK X:1000 -> A:1000 (C) > <-----------------/--------------------------- Host X > / > <---------------/ > (2) > > At (2), where is the INIT-ACK sent? There is one TCB in > the COOKIE-WAIT state that matches address C in the INIT, > and one TCB in the COOKIE-ECHOED state that matches C in > the INIT, neither match D. Let me see... Interesting cases you show... Here either D or X is an attacker... But let's see... Host X has shown that it owns address X, but not C... I don't know what I would do... Actually I think this was the same case you shown in your previous mails (the one about the malicious server), adding Host D to the game... If you join the associations, Host X might make you believe that he is also C when that might be false... but the idea that somebody to who you connect is an attacker... :-/ What do you propose? I don't know... Upon receipt of the INIT ACK from X, what about sending the COOKIE ECHO back to C?... Host X could well have three addresses, so this doesn't solve much... But I don't see any completely right solution... I think that I would join both associations upon the arrival of the INIT ACK, and then, when the INIT comes, I would send the INIT ACK back to C... This is a mess, but the whole situation is very weird... :-/ > INIT A:1000 -> C:1000 INIT D:1000 -> A:1000 (C) > ----------------------\ /------------------ Host D > \ / > INIT A:1000 -> X:1000 \/ > ----------------------\ /\ > X \-------------------> Host C > / \ > / \ > / \-------------------> Host X > / INIT-ACK X:1000 -> A:1000 (C) > <-----------------/--------------------------- Host X > COOKIE-ECHO / > ----------------/----------------------------> Host X > / COOKIE-ACK > <-------------/------------------------------- Host X > / > <-----------/ > (3) > > At (3) there is one TCB in the COOKIE-WAIT state that > matches address C in the INIT and on TCB in the COOKIE-ECHOED > state that matches D in the INIT. What is done about > the INIT-ACK? Is it discarded? Is it sent to C? I think this is a little easier than the previous. I would join both associations, and when the INIT comes, I would send the INIT ACK back to C... All this makes me think that at the end, sending the ABORT, doesn't seem to be a very bad idea :-) > Also consider n TCBs in various states, all that match > the address various addresses in the INIT. What is done > with the INIT-ACK in these cases of multiple matches? What do you propose? > Also there is a vulnerability in the COOKIE-ECHO state > in a separate mail. Ok, let's see it... > So, I don't know that I agree with 2.6. That is why I > do not yet follow it. I believe that it places too heavy > a reliance on a spoofable source address list in the INIT. Ok, what do you propose then? > I am not convinced that ever considering the spoofable > source address list in an INIT or INIT-ACK is wise from > the standpoint of security. Spoofing the source address > list is the easiest way to dream up vulnerabilities in > the INIT process. Same problems you have if you don't look at that address list. However, you have to wait till the reception of the COOKIE ECHO... In your implementation, taking your same example: INIT A:1000 -> C:1000 INIT D:1000 -> A:1000 (C) ----------------------\ /------------------ Host D \ / INIT A:1000 -> X:1000 \/ ----------------------\ /\ X \-------------------> Host C / \ / \ / \-------------------> Host X / INIT-ACK X:1000 -> A:1000 (C) <-----------------/--------------------------- Host X COOKIE-ECHO / ----------------/----------------------------> Host X / COOKIE-ACK <-------------/------------------------------- Host X / <-----------/ You can even forget about Host D. When the INIT ACK from Host X comes, what do you do? Address X has been verified, but what about address C...? Now I remember that you didn't answer to my mail where I think I found a probable attack based on this possibility that Host X doesn't own C... What do you do? It seems that you would simply copy the address list to the second TCB... When you receive the COOKIE ACK I suppose that you check all the other TCBs and find the first one, and join it with the second one... how proves you that Host X has address C? What do you do? > A procedure which thinks that one TCB will exist for a > given source address list address has not considered > source address list spoofing, and is likely insecure. All this cases only happen when the "attacker" knows that you are sending an INIT to an specific destination... But in any case, what do you propose? > See separate mail on COOKIE-ECHO state which exposes > a new vunlerabilty for that state based on INIT-ACK > source address list spoofing. Let's see... BR Iván Arias Rodríguez > --brian From owner-extdom.sctp-impl@sj-core-2.cisco.com Tue Mar 11 08:12:31 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18333 for ; Tue, 11 Mar 2003 08:12:29 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2BD21EY007978; Tue, 11 Mar 2003 05:02:02 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEJ64621; Tue, 11 Mar 2003 05:02:00 -0800 (PST) Message-ID: <3E6DDE47.8030407@cisco.com> Date: Tue, 11 Mar 2003 07:01:59 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: bidulock@openss7.org, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ivan: Ivan.Arias-Rodriguez@nokia.com wrote: > > > He didn't say it was common... At least what I understood was that it wasn't uncommon, which doesn't mean the same as far as I know... > > Saying that there is a case where it used to happen, doesn't mean that it is common... > > But again, you are changing words... :-/ > > He does tend to do that .. I said it was far more likely.. it is easy actually.. send a INIT to my web server at sctp.org... if you use the alternate address of the server you will likely get the INIT-ACK from the default route that points out the other interface... This is a more likely issue.. depending on how the default routes are placed and which address the peer chooses to send the INIT to, this case can happen quite often.... far more often than then a peer being unreachable on an address.. when I setup my network I use a little tool to test which addresses I can reach .. its called ping... this tends to be commonly used by folks and eliminates the "unreachable" issues often times... However routing tables get set the way folks put them in and often times are not as throughly tested. And most don't care which way the traffic is flowing.. as long as ping is responding... It always amazes me how when you discuss a subject, laying out carefully in a thread that a) addresses are NOT pre-known b) here is the scenario.. c) paint it carefully d) show where things break We seem to get a circle back to eliminate one of the conditions.. We have been discussing the above.. in conjunction with highlighted. > > >>of any vulnerability >>case is dependent upon the application and what the attacker >>does. Otherwise >>why would we spend so much time talking about corner cases? >> >> > > That's precisely what I think... Just state that iff you provide the list of addresses you don't need to inspect the address list... otherwise... it is your own risk... it may work most of the times... but it may not work sometimes... > > exactly > > >>Besides, mission critical applications that have a high cost >>associated >>with failing to make connections and require 5 or 6 nines of >>availability >>cannot afford to have the INIT process fail because one interface is >>temporarily unreachable. Our implementation is indeed >>intended to work in >>these environments. It appears that 2.6 is not. >> >> > > Your application works? > > Please, tell me how it does so, WITHOUT knowing in advance the list of addresses... This is what you shown... You show the case, you say your implementation is better, and everybody claps... What you didn't say is that your implementation is better IFF you have MORE information than the other implementation... Of course then it is better... of course! > > > >>> So, which option does your implementation choose, the >>> >>> >>bad or the worse? >> >>In our implementation, the cost of forming the connection in >>all circumstances >>is having the ULP supply the list of "known addresses" to the >>connect() command. >> >> > > So? > > Either you look at the address list or you know the addresses... But since you CANNOT know the addresses in advance in all the circumstances, you have to take a look to the addresses... > > The point of all this discussion is that you have to know all the addresses of the peer when you receive the INIT to be able to act consistently. You knew them before? Ok, don't look at them again, they are the same ones... > > > >>>>Our current implementation does not sacrifice this case >>>> >>>> >>> As I think, it sacrifices both, or it is open to >>> >>> >>attacks... As I said >> >> >>> above, I might be wrong as well... it is late and I'm >>> >>> >>tired... :-0 >> >>Yes, I believe you have it wrong, take a look again above. >> >> > > Same applies to you... > > No, I think Brian knows what you mean.. he is just changing the subject... > > >>>>(or the case where C is reachable) if D is supplied to >>>>connect(). The current implementation sacrifices the cases >>>>where D is not supplied to connect(). >>>> >>>> >>> See above... >>> >>> >>> >>>>For applications that can have a knowledge of D (e.g. from >>>>DNS lookup or static assignment) and requires a reliable >>>>INIT process our current implementation is superior to >>>> >>>> >>> Now that I think about it... I think this could be an >>> >>> >>improvement for >> >> >>> the INIT collision scenario... We could say that >>> >>> >>instead of sending >> >> >>> the INIT ACK to the destination address of the >>> >>> >>previously sent INIT, >> >> >>> we could use any of the "known addresses". The point is >>> >>> >>that the RFC >> >> >>> always considers that you only know one of the peer's >>> >>> >>addresses... But >> >> >>> this change would be completely equivalent and more >>> >>> >>general. However, >> >> >>> I don't know in how many places the RFC takes for >>> >>> >>granted that while >> >> >>> in the COOKIE WAIT state you know only one of the >>> >>> >>peer's addresses... >> >> >>> :-/ >>> >>> >>I don't see how this is so different from what our >>implementation does. It >> >> > > But knowing the addresses before the peer tells you them is not a need... and most of the times it will be even impossible... > > > >>allows the ULP to provide a list of "known addresses" to the >>connect(). This >> >> > > It seems that the connect() at the socket API for SCTP only takes one address. I don't follow this API so I do whatever I want. However, I think that it would be a good idea to modify it so instead of providing a sockaddr_in or sockaddr_in6 you can provide a list of them... > > Randall? (I doubt that other authors of the API draft are following this loooong thread) > > > I doubt that: a) My fellow co-authors of the socket-api will bother reading this looong thread.. not unless they are gluttons for punishment, and b) Will be to much in favor of adding a method to add "pre-known" addresses to the connect call... this really is not to feasable...One would need a special sctp_connect() and thus you would always have the possibility that connect() would still be called and you would not "pre-know" all the addresses.. and still need to deal with this case... Now here is my conclusion to this thread.. note I say conclusion .. I will not answer in it anymore.. My silence is not agreement... we have beat this topic to death!! I don't feel like re-hashing this argument. 1) I will go back through this looong thread and gather up the security issues that are in it. I will take these to Steve Bellovin and discuss with him (over drinks) what is and what is NOT issues to be concerned about. 2) We will get modifications for these issues into the IG as needed if there are any issues at all.. 3) I will discuss with my co-authors of the socket-api this sctp_connect() issue. R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Tue Mar 11 08:45:18 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19125 for ; Tue, 11 Mar 2003 08:45:15 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2BDfa0G011031; Tue, 11 Mar 2003 05:41:38 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEJ66468; Tue, 11 Mar 2003 05:41:35 -0800 (PST) Message-ID: <3E6DE78F.2010603@cisco.com> Date: Tue, 11 Mar 2003 07:41:35 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030311045000.B8489@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This one may be worth responding to since there is one new scenario... Brian F. G. Bidulock wrote: >Ivan, Randall, > >Here is a new source address spoof (DoS and hijack) attack >on the COOKIE-ECHOED state. 2.6 does not have this correct >yet (and neither does the RFC). > >IG Section 2.6 > > Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST > respond with an INIT ACK using the same parameters it sent in its > original INIT chunk (including its Initiation Tag, unchanged) > provided that no NEW address have been added to the forming > association. If the INIT message indicates that a new address(es) > have been added to the association, then the entire INIT MUST be > discarded and NO changes should be made to the existing association. > An ABORT MUST be sent in response that SHOULD include the error > 'Restart of an association with new addresses'. The error SHOULD list > the addresses that were added to the restarting association. > > >Host A/B Host X Host C/D > | | | > |INIT A:1000 -> X:1000 | | > |---------------------------------------------->| | > |TCB1: | | > |VT: X | | > |PT: 0 | | > |Loc: A:1000 | | > |Rem: X:1000 | | > |State: COOKIE-WAIT | | > | | | > | INIT-ACK X:1000 -> A:1000 (D)| | > |<----------------------------------------------| | > |(TCB1 is found) | | > | | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > |TCB1: | | > |VT: X | | > |PT: W | | > |Loc: A:1000 | | > |Rem: X:1000, D:1000 | | > |State: COOKIE-ECHOED | | > | X does not | | > | send (or delays) | > | COOKIE-ACK | | > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | >Note that X can keep the T1-cookie timeout initially high by >responding to a retransmitted INIT instead of the first INIT >above. T1-cookies doubles with each retransmission up to 60 >seconds, so the sequence is 3sec, 6sec, 12sec, 24sec, 48sec, >60sec, 60sec, 60sec which is 273 seconds or about 4 minutes. >There are ways to extend this period longer. > | | | > | INIT C:1000 -> A:1000 (D)| > |<-------------------------------------------------------| > | | | > |ABORT ERROR (Restart with new addresses) | | > |------------------------------------------------------->| > This is incorrect. You don't have an association yet.. you must reach established before you "restart with new addresses".. but as I said I think killing the "new addresses" error cause may be worthwhile to eliminate.. The abort without this error cause is better.. but its not applicable here... > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > | . | | > | . | | > | . | | > | | | > >Following IG Section 2.6 provides for DoS attack with spoofed >addresses in address list. > >Host X can refuse access to A for an arbitrary number of multi-homed >hosts, should A form an association with X. > > So here, you are just illustrating (if you let the cookie-ack go from X) a camped-on address scenario.. other than that, you have a collision case.. and again having a auditing mechanism for this case may be worthwhile... aka the HB of suspect associations... at startup... But this next case is the "new" one worth looking at... >Here is a reverse hijack: > >Host A/B Host X Host C > | | | > |INIT A:1000 -> X:1000 | | > |---------------------------------------------->| | > |TCB1: | | > |VT: X | | > |PT: 0 | | > |Loc: A:1000 | | > |Rem: X:1000 | | > |State: COOKIE-WAIT | | > | | | > | INIT-ACK X:1000 -> A:1000 (C)| | > |<----------------------------------------------| | > |(TCB1 is found) | | > | | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > |TCB1: | | > |VT: X | | > |PT: W | | > |Loc: A:1000 | | > |Rem: X:1000, C:1000 | | > |State: COOKIE-ECHOED | | > | X does not | | > | send (or delays) | > | COOKIE-ACK | | > So the association is not fully formed and you are in COOKIE-ECHOED state.. not established... > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > | . | | > | . | | > | . | | > | | | > | INIT (IT: Y) C:1000 -> A:1000| > |<-------------------------------------------------------| > | | | > And I believe RFC2960 states: " For an endpoint that is in the COOKIE-ECHOED state it MUST populate its Tie-Tags with the Tag information of itself and its peer (see section 5.2.2 for a description of the Tie-Tags). " > |INIT-ACK (IT: X, no tie tags) | | > |------------------------------------------------------->| > | | | > | COOKIE-ECHO C:1000 -> A:1000 | > |<-------------------------------------------------------| > |Action B | | > So you would have tie-tags... But I still think you would end at action B.. > |COOKIE-ACK A:1000 -> C:1000 | | > |------------------------------------------------------->| > |TCB1 | | > |VT: X | | > |PT: Y | | > |Loc: A:1000 | | > |Rem: X:1000, C:1000 | | > |State: ESTABLISHED | | > > And here is where you make a mistake.. and maybe because action-b's wording needs some updates. When the COOKIE-ECHO arrives and you take Action-B you would update your address list with only those addresses in the COOKIE. So your association would NOT include X. And of course you have two TCB and would need to collapse one of them... this again is where possibly having a special "hold" state to see who is who may be warrented... but, curently, the way our implementation works.. the other assocation (the one with X) would get aborted at least internally... and the other would hold VT's X/Y but the Address X would NOT be a part of the association... so if X did send in the a message it would be rejected... since X does not belong to the association.. no matter if the Vtag is correct or not... R >X now knows A's verification tag for its association with C. >X can know that the association is established with C because >COOKIE-ECHOs stop prematurely, or if A does not kick X out of >the TCB (not stated in RFC or IG), a DATA or HEARTBEAT will >eventually tell X that it is in the established state. DATA >or a HEARTBEAT would also tell X C's verification tag for the >association. Or, if X is not kicked out of the TCB, it could >send an INIT and read C's verification tag out of the tie tags >in the cookie in the INIT-ACK. > >If X is not kicked out of the TCB then one-way >eavesdropping is possible. > > | | | > |DATA (VT: Y) | | > |---------------------------------------------->|------->| > | | | > >Even if X is kicked out of the TCB, X knows A's verification tag >for the association between A and C. A simultaneous attack on >C could yeild C's verification tag for the association. > >A DoS attack would be to send an ABORT to A with the known VT >when the COOKE-ECHO is not received, and start the process again >with a new INIT. This DoS attack has the difference over the >previous one that no ERROR message is sent to C. > >To avoid this problem, INIT received in the COOKIE-ECHO state >needs to be treated the same as INIT in the ESTABLISHED state >(new verification tag chosen), or COOKIE-WAIT (sent to X or >known address of X). The former is preferrable because it >does not cause a new denial of service attack. > >Closing this latter vulnerability also removes the need to find >the existing TCB in the COOKIE-ECHO state based on the source >address list, because a new IT is generated and no tie tags >populated. > >--brian > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-2.cisco.com Tue Mar 11 08:51:42 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19263 for ; Tue, 11 Mar 2003 08:51:40 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2BDltEY006342 for ; Tue, 11 Mar 2003 05:47:56 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2BDlsYp028081 for ; Tue, 11 Mar 2003 05:47:55 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2BDlo7f027797 for ; Tue, 11 Mar 2003 05:47:58 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BDZnF07781 for ; Tue, 11 Mar 2003 15:35:50 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 15:32:23 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 15:32:22 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 15:32:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Tue, 11 Mar 2003 15:32:21 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLnxXoG7KYWMfBkS9iNWeiFZXngywABn+3A From: To: Cc: , , X-OriginalArrivalTime: 11 Mar 2003 13:32:22.0550 (UTC) FILETIME=[A57EE360:01C2E7D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA19263 Brian, > > Ivan, Randall, > > Here is a new source address spoof (DoS and hijack) attack > on the COOKIE-ECHOED state. 2.6 does not have this correct > yet (and neither does the RFC). > > IG Section 2.6 > > Upon receipt of an INIT in the COOKIE-ECHOED state, an > endpoint MUST > respond with an INIT ACK using the same parameters it sent in its > original INIT chunk (including its Initiation Tag, unchanged) > provided that no NEW address have been added to the forming > association. If the INIT message indicates that a new address(es) > have been added to the association, then the entire INIT MUST be > discarded and NO changes should be made to the existing > association. > An ABORT MUST be sent in response that SHOULD include the error > 'Restart of an association with new addresses'. The error > SHOULD list > the addresses that were added to the restarting association. > > > Host A/B Host X Host C/D > | | | > |INIT A:1000 -> X:1000 | | > |---------------------------------------------->| | > |TCB1: | | > |VT: X | | > |PT: 0 | | > |Loc: A:1000 | | > |Rem: X:1000 | | > |State: COOKIE-WAIT | | > | | | > | INIT-ACK X:1000 -> A:1000 (D)| | > |<----------------------------------------------| | > |(TCB1 is found) | | > | | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > |TCB1: | | > |VT: X | | > |PT: W | | > |Loc: A:1000 | | > |Rem: X:1000, D:1000 | | > |State: COOKIE-ECHOED | | > | X does not | | > | send (or delays) | > | COOKIE-ACK | | > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > Note that X can keep the T1-cookie timeout initially high by > responding to a retransmitted INIT instead of the first INIT > above. T1-cookies doubles with each retransmission up to 60 > seconds, so the sequence is 3sec, 6sec, 12sec, 24sec, 48sec, > 60sec, 60sec, 60sec which is 273 seconds or about 4 minutes. > There are ways to extend this period longer. > | | | > | INIT C:1000 -> A:1000 (D)| > |<-------------------------------------------------------| > | | | > |ABORT ERROR (Restart with new addresses) | | > |------------------------------------------------------->| > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > | . | | > | . | | > | . | | > | | | > > Following IG Section 2.6 provides for DoS attack with spoofed > addresses in address list. Well... I think that normally, an attacker is somebody that comes out of the shadow and tries to connect to you, not the opposite... You trying to connect to the attacker that tries a third party not to connect to you seems very weird... I'm not saying that it is completely impossible thought... However, in this case, one would normally think that the attacker is in fact Host C/D, not Host X... At the end, it was you the one that decided freely to connect to the attacker... I think that if somebody you try to connect with, results to be an attacker, one can easily ban him... I doubt that an attacker is going to be somebody that makes its service known enough so you decide to connect to him... after all, one takes a while to gain your confidence (so you try to connect to him), but it simply takes an attack to lose that confidence... I hope you follow what I'm saying... However, this situation has a (not very handy) solution. Let's see... Host C/D, seeing that somebody else has forged its address, decides to send an INIT including only one address. If the ABORT includes the extra addresses, it can simply try to establish an association without those ones. This will take the association out of Host X control. If both peers have AddIP, it is easy to add those other addresses later. If not, HOST C/D will have to ABORT the association and then try to establish it again with all the addresses. Of course, during this time Host X may try again to be faster than Host C/D and again keep control of the association... :-( Now that I think about it... You may hate what I'm going to say, but... you may not... :-) All these problems about hijacking associations and DOS come because the peer didn't show that it really owns the address inside the address list... Why not adding some kind of option that tells the peer to "show" its ownership right after establishing the association? However, I fail to see how this could be done... You can only show the ownership if you reply to something sent to that address... And I guess that again the HB mechanism would be the best one... I think that in cases where an incoming INIT (not sure about the INIT ACK) adds new addresses (maybe only in cases where the INIT conflicts only with one association), one should try to verify the new addresses included inside the INIT... However, this is not very good idea either... Since you have to send a packet (in order to receive the reply) to verify one address, this could lead to packet multiplication... unless we make first the peer to send to us that same quantity of packets or something... hmm... Any idea? > Host X can refuse access to A for an arbitrary number of multi-homed > hosts, should A form an association with X. But this is the problem... Why would A want to make an association with an attacker? As soon as one realizes that it is an attacker, you will never connect to that host... I don't really think this attack will be possible to do in the real world... :-/ > Here is a reverse hijack: > > Host A/B Host X Host C > | | | > |INIT A:1000 -> X:1000 | | > |---------------------------------------------->| | > |TCB1: | | > |VT: X | | > |PT: 0 | | > |Loc: A:1000 | | > |Rem: X:1000 | | > |State: COOKIE-WAIT | | > | | | > | INIT-ACK X:1000 -> A:1000 (C)| | > |<----------------------------------------------| | > |(TCB1 is found) | | > | | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > |TCB1: | | > |VT: X | | > |PT: W | | > |Loc: A:1000 | | > |Rem: X:1000, C:1000 | | > |State: COOKIE-ECHOED | | > | X does not | | > | send (or delays) | > | COOKIE-ACK | | > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > | | | > |T1-cookie timeout | | > |COOKIE-ECHO A:1000->X:1000 | | > |---------------------------------------------->| | > | . | | > | . | | > | . | | > | | | > | INIT (IT: Y) C:1000 -> A:1000| > |<-------------------------------------------------------| > | | | > |INIT-ACK (IT: X, no tie tags) | | > |------------------------------------------------------->| > | | | > | COOKIE-ECHO C:1000 -> A:1000 | > |<-------------------------------------------------------| > |Action B | | > |COOKIE-ACK A:1000 -> C:1000 | | > |------------------------------------------------------->| > |TCB1 | | > |VT: X | | > |PT: Y | | > |Loc: A:1000 | | > |Rem: X:1000, C:1000 | | > |State: ESTABLISHED | | > > X now knows A's verification tag for its association with C. Hmm... no... And this is not even an attack, it is "recovering what is yours"... I don't accept this case... This is actually the way Host C would defend from the situation above... Host C sends the INIT, and Host A is in ESTABLISHED, so, as it doesn't add addresses, it replies to C including a NEW IT and also the Tie Tags... At the end, Host C will have its association with Host A, and Host X (the attacker) will lose control over address C, which is not one of its addresses... X doesn't know any VT since Host A included a NEW IT inside the INIT ACK sent to C... That's in section 5.2.2... Now that I think about new addresses and stuff... Is it there any danger about hijacking another established association, if the new addresses are inside the address list? I mean... If somebody claiming to be in this case above, C, includes more addresses inside the address list, but still proves to be C (since it replies to the INIT ACK), isn't he in fact the legitimate owner of any other association that is using C? In the case above... Does it really make sense to send an ABORT to C if it would also include, let's say, address D? I don't think so... If it replies to the INIT ACK sent to C, he is C, and thus, I think we should immediately close the other association... The rules for this would be something like: - If the INIT adding new addresses to an association comes from any of the "known addresses", then act as if it wouldn't be adding addresses. - If the INIT adding new addresses to an association comes from any "unknown address", then act "taking care" (either sending the ABORT -which may not be the best idea-, or sending the INIT ACK back to any of the "known addresses" included in the new INIT). This way we would avoid these problems about "malicious servers"... Does it make sense? I haven't thought much about it, I might have made a terrible mistake somewhere... > X can know that the association is established with C because > COOKIE-ECHOs stop prematurely, or if A does not kick X out of > the TCB (not stated in RFC or IG), a DATA or HEARTBEAT will > eventually tell X that it is in the established state. DATA > or a HEARTBEAT would also tell X C's verification tag for the > association. Or, if X is not kicked out of the TCB, it could > send an INIT and read C's verification tag out of the tie tags > in the cookie in the INIT-ACK. No... Since you didn't get the VT any of the above is a real treat... > If X is not kicked out of the TCB then one-way > eavesdropping is possible. > > | | | > |DATA (VT: Y) | | > |---------------------------------------------->|------->| > | | | > Yes, X is taken away, since you restart the association, you rebuild the TCB and only include those addresses that C told you to include... The fact that Host A chose a new IT is what makes your assumptions false... sorry... though the idea was interesting... > Even if X is kicked out of the TCB, X knows A's verification tag > for the association between A and C. A simultaneous attack on > C could yeild C's verification tag for the association. This would have been a terrible hole in security for TCB in my opinion... But this hole doesn't, fortunately, exist... > A DoS attack would be to send an ABORT to A with the known VT > when the COOKE-ECHO is not received, and start the process again > with a new INIT. This DoS attack has the difference over the > previous one that no ERROR message is sent to C. Interesting, but impossible... > To avoid this problem, INIT received in the COOKIE-ECHO state > needs to be treated the same as INIT in the ESTABLISHED state > (new verification tag chosen), or COOKIE-WAIT (sent to X or > known address of X). The former is preferrable because it > does not cause a new denial of service attack. See above... > Closing this latter vulnerability also removes the need to find > the existing TCB in the COOKIE-ECHO state based on the source > address list, because a new IT is generated and no tie tags > populated. I love that you always reach the same conclusion... :-) Sorry Brian, this attack is not possible to perform... BR Iván Arias Rodríguez > --brian > > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > From owner-extdom.sctp-impl@sj-core-2.cisco.com Tue Mar 11 11:06:46 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24996 for ; Tue, 11 Mar 2003 11:06:44 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2BFqLEY009785 for ; Tue, 11 Mar 2003 07:52:21 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2BFqKtm021926 for ; Tue, 11 Mar 2003 07:52:20 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2BFqG7f013561 for ; Tue, 11 Mar 2003 07:52:24 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BFSuF10212 for ; Tue, 11 Mar 2003 17:28:56 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 17:25:29 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 17:25:28 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 17:25:27 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 17:25:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Tue, 11 Mar 2003 17:25:26 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLn1AanR+6yLzlFRj22J3BaSxfRBwABRIJQ From: To: , Cc: X-OriginalArrivalTime: 11 Mar 2003 15:25:27.0371 (UTC) FILETIME=[719069B0:01C2E7E2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA24996 Brian, Randall, I made a mistake in my earlier response... ... snip... > >Here is a reverse hijack: > > > >Host A/B Host X Host C > > | | | > > |INIT A:1000 -> X:1000 | | > > |---------------------------------------------->| | > > |TCB1: | | > > |VT: X | | > > |PT: 0 | | > > |Loc: A:1000 | | > > |Rem: X:1000 | | > > |State: COOKIE-WAIT | | > > | | | > > | INIT-ACK X:1000 -> A:1000 (C)| | > > |<----------------------------------------------| | > > |(TCB1 is found) | | > > | | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > |TCB1: | | > > |VT: X | | > > |PT: W | | > > |Loc: A:1000 | | > > |Rem: X:1000, C:1000 | | > > |State: COOKIE-ECHOED | | > > | X does not | | > > | send (or delays) | > > | COOKIE-ACK | | > > > > So the association is not fully formed and you are in > COOKIE-ECHOED state.. not established... This was my mistake... Alright, it is in the COOKIE ECHOED state... > > | | | > > |T1-cookie timeout | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > | | | > > |T1-cookie timeout | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > | . | | > > | . | | > > | . | | > > | | | > > | INIT (IT: Y) C:1000 -> A:1000| > > |<-------------------------------------------------------| > > | | | > > > And I believe RFC2960 states: > " > For an endpoint that is in the COOKIE-ECHOED state it MUST populate > its Tie-Tags with the Tag information of itself and its peer (see > section 5.2.2 for a description of the Tie-Tags). > " By the way, Randall... there is a mistake in the IG, in the Note of the new text for section 5.2.2... It is a cut & paste error. That Note shouldn't include the COOKIE ECHOED state... Most probably this is what confused Brian here... > > |INIT-ACK (IT: X, no tie tags) | | > > |------------------------------------------------------->| > > | | | > > | COOKIE-ECHO C:1000 -> A:1000 | > > |<-------------------------------------------------------| > > |Action B | | > > > So you would have tie-tags... But I still think you would > end at action B.. Yes... > > |COOKIE-ACK A:1000 -> C:1000 | | > > |------------------------------------------------------->| > > |TCB1 | | > > |VT: X | | > > |PT: Y | | > > |Loc: A:1000 | | > > |Rem: X:1000, C:1000 | | > > |State: ESTABLISHED | | > > > > > And here is where you make a mistake.. and maybe because action-b's > wording needs some updates. > > When the COOKIE-ECHO arrives and you take Action-B you would > update your address list with only those addresses in the COOKIE. This is what I have always understood... I just rebuild the TCB (not erasing the data but putting it apart), and send a notification to the user... Maybe we should state this in section 5.2.4 (for all the cases?) > So your association would NOT include X. And of course you > have two TCB and would need to collapse one of them... this > again is where possibly having a special "hold" state to see > who is who may be warrented... but, curently, the way our The "old" association (which was never formed but there was a TCB for it) will become the new one... I will take all the information from the cookie and replace the old one... > implementation works.. the other assocation (the one with > X) would get aborted at least internally... and the other > would hold VT's X/Y but the Address X would NOT be > a part of the association... so if X did send in the > a message it would be rejected... since X does not belong > to the association.. no matter if the Vtag is correct or > not... It can forge the source... It could even try to add itself to the association again... forging the A address... However, let me see... No, that's not possible... X should send the ASCONF to A using C as its source address. Then, C would receive the ASCONF ACK and it would send an ABORT with the "Association Aborted due to illegal ASCONF-ACK", and the association will crash... > R > > >X now knows A's verification tag for its association with C. > >X can know that the association is established with C because > >COOKIE-ECHOs stop prematurely, or if A does not kick X out of > >the TCB (not stated in RFC or IG), a DATA or HEARTBEAT will > >eventually tell X that it is in the established state. DATA > >or a HEARTBEAT would also tell X C's verification tag for the > >association. Or, if X is not kicked out of the TCB, it could > >send an INIT and read C's verification tag out of the tie tags > >in the cookie in the INIT-ACK. Well... this I think won't be possible... It should include X, thus, it would be adding addresses... Either it will get an ABORT back (as per the IG), or the INIT ACK will go to C (the other option we have been thinking about)... In any case, it won't get the INIT ACK back... > >If X is not kicked out of the TCB then one-way > >eavesdropping is possible. > > > > | | | > > |DATA (VT: Y) | | > > |---------------------------------------------->|------->| > > | | | > > > >Even if X is kicked out of the TCB, X knows A's verification tag > >for the association between A and C. A simultaneous attack on > >C could yeild C's verification tag for the association. Uff... this will be almost impossible... if not completely... let me think... First, you will have to know that both peer want to establish an association, which is not a very big deal though... Then, both Hosts A and C, before connecting each other, should connect you (really, really unrealistic, why would they want to do so if you want to attack them?). After keeping them for a while in the COOKIE ECHOED state, they should try to connect to each other. However, they are already trying to connect to each other (or so they think), so, they will not send any INIT or stuff... This case won't be possible... > >A DoS attack would be to send an ABORT to A with the known VT > >when the COOKE-ECHO is not received, and start the process again > >with a new INIT. This DoS attack has the difference over the > >previous one that no ERROR message is sent to C. But this DOS attack is really unrealistic... It is done by a "friend"... If Host A tries to connect to X that's because A "knows" X... I don't know how an attacker could attract you to him, instead of he coming to you... > >To avoid this problem, INIT received in the COOKIE-ECHO state > >needs to be treated the same as INIT in the ESTABLISHED state > >(new verification tag chosen), or COOKIE-WAIT (sent to X or > >known address of X). The former is preferrable because it > >does not cause a new denial of service attack. It is really easy to say it... You don't know which other consequences this might have... All the other cases should be taken into account... But this might be worthy to study... however, only if people with expertise in security think that this possibility of attack really makes sense noticing... > >Closing this latter vulnerability also removes the need to find > >the existing TCB in the COOKIE-ECHO state based on the source > >address list, because a new IT is generated and no tie tags > >populated. You should populate the tie tags, thus, you must find the TCB. Otherwise you would receive a Cookie in which the VTs don't match, and the Tie Tags are set to 0, so you would discard it and the association won't come up... Thus, doing that (so you avoid checking the address list) precisely is what would make impossible for Host C to establish a legitimate association... Since you need to populate the Tie Tags, you need to check the address list... But thanks for your efforts... So far I think we (you don't have to include yourself if you don't want) have agreed about some changes in the IG due to your perseverance. At least I can think about: a) Should we include the new addresses added in the "new addresses..." cause of error when sending the ABORT as a response to an INIT adding addresses? Should we include the error cause at all? Should we send the ABORT at all? Should we instead send the INIT ACK to *any* of the known addresses? b) Should we really apply the "new addresses added" procedure if the INIT comes from a "known address"? c) We should make some changes to the explanation of the action to be performed upon receipt of a duplicate COOKIE ECHO. Explaining that the new address should be used, and, at least I remember for the C) case, stating that a COOKIE ACK should be sent back. d) The Note at the end of the new text for section 5.2.2 is wrong. It shouldn't include the COOKIE ECHO state. ... BR Iván Arias Rodríguez > >--brian > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > From owner-extdom.sctp-impl@sj-core-2.cisco.com Tue Mar 11 11:11:11 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25107 for ; Tue, 11 Mar 2003 11:11:09 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2BG03EY016185; Tue, 11 Mar 2003 08:00:04 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEJ75431; Tue, 11 Mar 2003 08:00:02 -0800 (PST) Message-ID: <3E6E0801.8030803@cisco.com> Date: Tue, 11 Mar 2003 10:00:01 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: bidulock@openss7.org, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, Randall, > > I made a mistake in my earlier response... > > ... snip... > > > >>>Here is a reverse hijack: >>> >>>Host A/B Host X Host C >>> | | | >>> |INIT A:1000 -> X:1000 | | >>> |---------------------------------------------->| | >>> |TCB1: | | >>> |VT: X | | >>> |PT: 0 | | >>> |Loc: A:1000 | | >>> |Rem: X:1000 | | >>> |State: COOKIE-WAIT | | >>> | | | >>> | INIT-ACK X:1000 -> A:1000 (C)| | >>> |<----------------------------------------------| | >>> |(TCB1 is found) | | >>> | | | >>> |COOKIE-ECHO A:1000->X:1000 | | >>> |---------------------------------------------->| | >>> |TCB1: | | >>> |VT: X | | >>> |PT: W | | >>> |Loc: A:1000 | | >>> |Rem: X:1000, C:1000 | | >>> |State: COOKIE-ECHOED | | >>> | X does not | | >>> | send (or delays) | >>> | COOKIE-ACK | | >>> >>> >>> >>So the association is not fully formed and you are in >>COOKIE-ECHOED state.. not established... >> >> > > This was my mistake... Alright, it is in the COOKIE ECHOED state... > > > >>> | | | >>> |T1-cookie timeout | | >>> |COOKIE-ECHO A:1000->X:1000 | | >>> |---------------------------------------------->| | >>> | | | >>> |T1-cookie timeout | | >>> |COOKIE-ECHO A:1000->X:1000 | | >>> |---------------------------------------------->| | >>> | . | | >>> | . | | >>> | . | | >>> | | | >>> | INIT (IT: Y) C:1000 -> A:1000| >>> |<-------------------------------------------------------| >>> | | | >>> >>> >>> >>And I believe RFC2960 states: >>" >> For an endpoint that is in the COOKIE-ECHOED state it MUST populate >> its Tie-Tags with the Tag information of itself and its peer (see >> section 5.2.2 for a description of the Tie-Tags). >>" >> >> > > By the way, Randall... there is a mistake in the IG, in the Note of the new text for section 5.2.2... It is a cut & paste error. That Note shouldn't include the COOKIE ECHOED state... Most probably this is what confused Brian here... > > Yep.. a cut and paste error.. I will get a fix into the xml for -09 > > >>> |INIT-ACK (IT: X, no tie tags) | | >>> |------------------------------------------------------->| >>> | | | >>> | COOKIE-ECHO C:1000 -> A:1000 | >>> |<-------------------------------------------------------| >>> |Action B | | >>> >>> >>> >>So you would have tie-tags... But I still think you would >>end at action B.. >> >> > > Yes... > > > >>> |COOKIE-ACK A:1000 -> C:1000 | | >>> |------------------------------------------------------->| >>> |TCB1 | | >>> |VT: X | | >>> |PT: Y | | >>> |Loc: A:1000 | | >>> |Rem: X:1000, C:1000 | | >>> |State: ESTABLISHED | | >>> >>> >>> >>> >>And here is where you make a mistake.. and maybe because action-b's >>wording needs some updates. >> >>When the COOKIE-ECHO arrives and you take Action-B you would >>update your address list with only those addresses in the COOKIE. >> >> > > This is what I have always understood... I just rebuild the TCB (not erasing the data but putting it apart), and send a notification to the user... Maybe we should state this in section 5.2.4 (for all the cases?) > > Yep.. this is what I am thinking.. it is not clear enough evidently... > > >>So your association would NOT include X. And of course you >>have two TCB and would need to collapse one of them... this >>again is where possibly having a special "hold" state to see >>who is who may be warrented... but, curently, the way our >> >> > > The "old" association (which was never formed but there was a TCB for it) will become the new one... I will take all the information from the cookie and replace the old one... > > > >>implementation works.. the other assocation (the one with >>X) would get aborted at least internally... and the other >>would hold VT's X/Y but the Address X would NOT be >>a part of the association... so if X did send in the >>a message it would be rejected... since X does not belong >>to the association.. no matter if the Vtag is correct or >>not... >> >> > > It can forge the source... It could even try to add itself to the association again... forging the A address... However, let me see... No, that's not possible... > > X should send the ASCONF to A using C as its source address. Then, C would receive the ASCONF ACK and it would send an ABORT with the "Association Aborted due to illegal ASCONF-ACK", and the association will crash... > > M Tuexen and I are going to be working on a Public Key Chunk draft ... we think.. we will discuss it next time we get together.. R > > >>R >> >> >> >>>X now knows A's verification tag for its association with C. >>>X can know that the association is established with C because >>>COOKIE-ECHOs stop prematurely, or if A does not kick X out of >>>the TCB (not stated in RFC or IG), a DATA or HEARTBEAT will >>>eventually tell X that it is in the established state. DATA >>>or a HEARTBEAT would also tell X C's verification tag for the >>>association. Or, if X is not kicked out of the TCB, it could >>>send an INIT and read C's verification tag out of the tie tags >>>in the cookie in the INIT-ACK. >>> >>> > > Well... this I think won't be possible... It should include X, thus, it would be adding addresses... Either it will get an ABORT back (as per the IG), or the INIT ACK will go to C (the other option we have been thinking about)... In any case, it won't get the INIT ACK back... > > > >>>If X is not kicked out of the TCB then one-way >>>eavesdropping is possible. >>> >>> | | | >>> |DATA (VT: Y) | | >>> |---------------------------------------------->|------->| >>> | | | >>> >>>Even if X is kicked out of the TCB, X knows A's verification tag >>>for the association between A and C. A simultaneous attack on >>>C could yeild C's verification tag for the association. >>> >>> > > Uff... this will be almost impossible... if not completely... let me think... > > First, you will have to know that both peer want to establish an association, which is not a very big deal though... Then, both Hosts A and C, before connecting each other, should connect you (really, really unrealistic, why would they want to do so if you want to attack them?). After keeping them for a while in the COOKIE ECHOED state, they should try to connect to each other. However, they are already trying to connect to each other (or so they think), so, they will not send any INIT or stuff... > > This case won't be possible... > > > >>>A DoS attack would be to send an ABORT to A with the known VT >>>when the COOKE-ECHO is not received, and start the process again >>>with a new INIT. This DoS attack has the difference over the >>>previous one that no ERROR message is sent to C. >>> >>> > > But this DOS attack is really unrealistic... It is done by a "friend"... If Host A tries to connect to X that's because A "knows" X... > > I don't know how an attacker could attract you to him, instead of he coming to you... > > > >>>To avoid this problem, INIT received in the COOKIE-ECHO state >>>needs to be treated the same as INIT in the ESTABLISHED state >>>(new verification tag chosen), or COOKIE-WAIT (sent to X or >>>known address of X). The former is preferrable because it >>>does not cause a new denial of service attack. >>> >>> > > It is really easy to say it... You don't know which other consequences this might have... All the other cases should be taken into account... But this might be worthy to study... however, only if people with expertise in security think that this possibility of attack really makes sense noticing... > > > >>>Closing this latter vulnerability also removes the need to find >>>the existing TCB in the COOKIE-ECHO state based on the source >>>address list, because a new IT is generated and no tie tags >>>populated. >>> >>> > > You should populate the tie tags, thus, you must find the TCB. Otherwise you would receive a Cookie in which the VTs don't match, and the Tie Tags are set to 0, so you would discard it and the association won't come up... > > Thus, doing that (so you avoid checking the address list) precisely is what would make impossible for Host C to establish a legitimate association... > > Since you need to populate the Tie Tags, you need to check the address list... > > But thanks for your efforts... So far I think we (you don't have to include yourself if you don't want) have agreed about some changes in the IG due to your perseverance. At least I can think about: > > a) Should we include the new addresses added in the "new addresses..." cause of error when sending the ABORT as a response to an INIT adding addresses? Should we include the error cause at all? Should we send the ABORT at all? Should we instead send the INIT ACK to *any* of the known addresses? > > b) Should we really apply the "new addresses added" procedure if the INIT comes from a "known address"? > > c) We should make some changes to the explanation of the action to be performed upon receipt of a duplicate COOKIE ECHO. Explaining that the new address should be used, and, at least I remember for the C) case, stating that a COOKIE ACK should be sent back. > > d) The Note at the end of the new text for section 5.2.2 is wrong. It shouldn't include the COOKIE ECHO state. > > ... > > BR Iván Arias Rodríguez > > > >>>--brian >>> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> >> > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-2.cisco.com Tue Mar 11 12:47:00 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29438 for ; Tue, 11 Mar 2003 12:46:59 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2BHelEY020737 for ; Tue, 11 Mar 2003 09:40:48 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2BHe42m017882 for ; Tue, 11 Mar 2003 09:40:04 -0800 (PST) Received: from thebe.your-site.com (lists.your-site.com [140.186.45.30]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2BHeh7f024245 for ; Tue, 11 Mar 2003 09:40:51 -0800 (PST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 4DB9F244E3A; Tue, 11 Mar 2003 12:36:06 -0500 (EST) Date: Tue, 11 Mar 2003 11:37:49 -0600 From: Caitlin Bestler Subject: Re: Matching addresses in INIT and INIT ACK To: sctp-impl@external.cisco.com Cc: Ivan.Arias-Rodriguez@nokia.com, rrs@cisco.com, bidulock@openss7.org X-Priority: 3 In-Reply-To: <20030311045000.B8489@openss7.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit On 3/11/03, Brian F. G. Bidulock wrote: << scenario deleted>> > >Host X can refuse access to A for an arbitrary number of >multi-homed hosts, should A form an association with X. > As a general rule attackers do not provide a valid return address. But it is true that an attacker could pre-empt a large number of IP addresses by falsely claiming they were valid endpoints for it. But it's not a real concern. Some de facto standards that are very relevant... A network administrator SHOULD be able to determine which of their users was the source of any packet originated from their network. When presented with solid evidence that these packets were part of an attack, the user's accont SHOULD be terminated. If a network administrator does not comply with the above, other network administators MAY blacklist the entire network. Legitimate customers of the blacklisted network SHOULD get angry with their network administrator, who SHOULD find themselves in need of new employment. Only the most idiotic attacker in the world would send packets designed to cause a Denial of Service *after* their victim has successfully sent a return packet. Basically, existing administrative procedures are already in place that would prevent this strategy from being used. It does not need an SCTP specific solution. That does leave a minor issue of mistaken configuration. The address block was recently split, and host X hasn't updated its INIT-ACK initialization to reflect the change yet. Unlikely, but still slightly valuable as a scenario. Personally, I would expect more problems from delays in updating routing tables. But anyway, I could see adding the following language somewhere along these lines: An SCTP implementation MAY choose to test a specific endpoint listed for its peer if it has reason to believe that the endpoint might not legitimately belong to the peer. Reasons for suspecting a problem would include prior configuration data, or conflicting information from other INITs. An SCTP implementation SHOULD NOT verify all peer addresses based simply on lack of confirmation. This could result in excessive network traffic. More realistically, it would probably be a good strategy to log conflicts on which remote IP addresses are bound together for inspection by the network administrator, provided that the logging is rate limited so that it cannot be an avenue for a DoS attack. If the set of addresses for a remote host is unstable it probably represents a configuration error or change. Actual changes should be rare enough that logging them is not much of an issue. And while there is certainly no obligation, passing along a probable configuration error for human review is certainly a nice thing to do. Caitlin Bestler http://asomi.com/CaitlinBestler/ From owner-extdom.sctp-impl@sj-core-2.cisco.com Tue Mar 11 14:20:50 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05423 for ; Tue, 11 Mar 2003 14:20:48 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2BJFfEY006246 for ; Tue, 11 Mar 2003 11:15:42 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2BJFfXZ012622 for ; Tue, 11 Mar 2003 11:15:41 -0800 (PST) Received: from gw.openss7.com (IDENT:1eodp/kGakRYbdsXAn5mcKfOHp5TKIxg@[142.179.199.224]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2BJFCTP004176 for ; Tue, 11 Mar 2003 11:15:17 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:pcRdj9DaMm9nwy8vupZECQ4OvMqCiyjH@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2BJ6ED10406; Tue, 11 Mar 2003 12:06:14 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2BJ6DM19981; Tue, 11 Mar 2003 12:06:13 -0700 Date: Tue, 11 Mar 2003 12:06:13 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: rrs@cisco.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030311120613.A19001@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Tue, Mar 11, 2003 at 03:32:21PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan, On Tue, 11 Mar 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > > > > Ivan, Randall, > > > > Here is a new source address spoof (DoS and hijack) attack > > on the COOKIE-ECHOED state. 2.6 does not have this correct > > yet (and neither does the RFC). > > > > IG Section 2.6 > > > > Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST > > respond with an INIT ACK using the same parameters it sent in its > > original INIT chunk (including its Initiation Tag, unchanged) > > provided that no NEW address have been added to the forming > > association. If the INIT message indicates that a new address(es) > > have been added to the association, then the entire INIT MUST be > > discarded and NO changes should be made to the existing association. > > An ABORT MUST be sent in response that SHOULD include the error > > 'Restart of an association with new addresses'. The error SHOULD list > > the addresses that were added to the restarting association. > > [snip] Please look at this second case again. Host A is in the COOKIE-ECHOED state (not the ESTABLISHED state) and is require to use the same VT per the paragraph quoted above (and a similar paragraph in the RFC). Host C is not adding new addresses with its INIT. > > Here is a reverse hijack: > > > > Host A/B Host X Host C > > | | | > > |INIT A:1000 -> X:1000 | | > > |---------------------------------------------->| | > > |TCB1: | | > > |VT: X | | > > |PT: 0 | | > > |Loc: A:1000 | | > > |Rem: X:1000 | | > > |State: COOKIE-WAIT | | > > | | | > > | INIT-ACK X:1000 -> A:1000 (C)| | > > |<----------------------------------------------| | > > |(TCB1 is found) | | > > | | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > |TCB1: | | > > |VT: X | | > > |PT: W | | > > |Loc: A:1000 | | > > |Rem: X:1000, C:1000 | | > > |State: COOKIE-ECHOED | | > > | X does not | | > > | send (or delays) | > > | COOKIE-ACK | | > > | | | > > |T1-cookie timeout | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > | | | > > |T1-cookie timeout | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > | . | | > > | . | | > > | . | | > > | | | > > | INIT (IT: Y) C:1000 -> A:1000| > > |<-------------------------------------------------------| > > | | | > > |INIT-ACK (IT: X, no tie tags) | | > > |------------------------------------------------------->| > > | | | > > | COOKIE-ECHO C:1000 -> A:1000 | > > |<-------------------------------------------------------| > > |Action B | | > > |COOKIE-ACK A:1000 -> C:1000 | | > > |------------------------------------------------------->| > > |TCB1 | | > > |VT: X | | > > |PT: Y | | > > |Loc: A:1000 | | > > |Rem: X:1000, C:1000 | | > > |State: ESTABLISHED | | > > > > X now knows A's verification tag for its association with C. > > Hmm... no... And this is not even an attack, it is "recovering what is > yours"... I don't accept this case... This is actually the way Host C > would defend from the situation above... > > Host C sends the INIT, and Host A is in ESTABLISHED, so, as it doesn't > add addresses, it replies to C including a NEW IT and also the Tie > Tags... At the end, Host C will have its association with Host A, and > Host X (the attacker) will lose control over address C, which is not > one of its addresses... Please look again, Host A is in the COOKIE-ECHOED state when the INIT arrives. [snip] (Your further comments assuming Host A in ESTABLISHED state do not apply.) > > > X can know that the association is established with C because > > COOKIE-ECHOs stop prematurely, or if A does not kick X out of > > the TCB (not stated in RFC or IG), a DATA or HEARTBEAT will > > eventually tell X that it is in the established state. DATA > > or a HEARTBEAT would also tell X C's verification tag for the > > association. Or, if X is not kicked out of the TCB, it could > > send an INIT and read C's verification tag out of the tie tags > > in the cookie in the INIT-ACK. > > If X is not kicked out of the TCB then one-way > > eavesdropping is possible. > > > > | | | > > |DATA (VT: Y) | | > > |---------------------------------------------->|------->| > > | | | > > > > Even if X is kicked out of the TCB, X knows A's verification tag > > for the association between A and C. A simultaneous attack on > > C could yeild C's verification tag for the association. > > > > A DoS attack would be to send an ABORT to A with the known VT > > when the COOKE-ECHO is not received, and start the process again > > with a new INIT. This DoS attack has the difference over the > > previous one that no ERROR message is sent to C. > > > > To avoid this problem, INIT received in the COOKIE-ECHO state > > needs to be treated the same as INIT in the ESTABLISHED state > > (new verification tag chosen), or COOKIE-WAIT (sent to X or > > known address of X). The former is preferrable because it > > does not cause a new denial of service attack. > > > > Closing this latter vulnerability also removes the need to find > > the existing TCB in the COOKIE-ECHO state based on the source > > address list, because a new IT is generated and no tie tags > > populated. > > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Tue Mar 11 16:19:44 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12701 for ; Tue, 11 Mar 2003 16:19:41 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2BLF70E011710 for ; Tue, 11 Mar 2003 13:15:07 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2BLF5gH019483 for ; Tue, 11 Mar 2003 13:15:06 -0800 (PST) Received: from gw.openss7.com (IDENT:d5b0WoeGJfmxvL5nTuD6ka8Y0DXxhoHH@[142.179.199.224]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2BLF07f016581 for ; Tue, 11 Mar 2003 13:15:07 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:a+LyMAcKjYybrDhTN8CWjpLAsSHOp2U3@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2BL6tD12345; Tue, 11 Mar 2003 14:06:55 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2BL6k023673; Tue, 11 Mar 2003 14:06:46 -0700 Date: Tue, 11 Mar 2003 14:06:46 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030311140645.B19001@openss7.org> Reply-To: bidulock@openss7.org References: <20030311045000.B8489@openss7.org> <3E6DE78F.2010603@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E6DE78F.2010603@cisco.com>; from rrs@cisco.com on Tue, Mar 11, 2003 at 07:41:35AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Tue, 11 Mar 2003, Randall Stewart (cisco) wrote: > This one may be worth responding to since > there is one new scenario... > > Brian F. G. Bidulock wrote: > > >Ivan, Randall, > > > >Here is a new source address spoof (DoS and hijack) attack > >on the COOKIE-ECHOED state. 2.6 does not have this correct > >yet (and neither does the RFC). > > > >IG Section 2.6 > > > > Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST > > respond with an INIT ACK using the same parameters it sent in its > > original INIT chunk (including its Initiation Tag, unchanged) > > provided that no NEW address have been added to the forming > > association. If the INIT message indicates that a new address(es) > > have been added to the association, then the entire INIT MUST be > > discarded and NO changes should be made to the existing association. > > An ABORT MUST be sent in response that SHOULD include the error > > 'Restart of an association with new addresses'. The error SHOULD list > > the addresses that were added to the restarting association. > > > > > >Host A/B Host X Host C/D > > | | | > > |INIT A:1000 -> X:1000 | | > > |---------------------------------------------->| | > > |TCB1: | | > > |VT: X | | > > |PT: 0 | | > > |Loc: A:1000 | | > > |Rem: X:1000 | | > > |State: COOKIE-WAIT | | > > | | | > > | INIT-ACK X:1000 -> A:1000 (D)| | > > |<----------------------------------------------| | > > |(TCB1 is found) | | > > | | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > |TCB1: | | > > |VT: X | | > > |PT: W | | > > |Loc: A:1000 | | > > |Rem: X:1000, D:1000 | | > > |State: COOKIE-ECHOED | | > > | X does not | | > > | send (or delays) | > > | COOKIE-ACK | | > > | | | > > |T1-cookie timeout | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > | | | > > |T1-cookie timeout | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > >Note that X can keep the T1-cookie timeout initially high by > >responding to a retransmitted INIT instead of the first INIT > >above. T1-cookies doubles with each retransmission up to 60 > >seconds, so the sequence is 3sec, 6sec, 12sec, 24sec, 48sec, > >60sec, 60sec, 60sec which is 273 seconds or about 4 minutes. > >There are ways to extend this period longer. > > | | | > > | INIT C:1000 -> A:1000 (D)| > > |<-------------------------------------------------------| > > | | | > > |ABORT ERROR (Restart with new addresses) | | > > |------------------------------------------------------->| > > > > This is incorrect. You don't have an association yet.. you > must reach established before you "restart with new addresses".. but > as I said I think killing the "new addresses" error cause may > be worthwhile to eliminate.. The abort without this > error cause is better.. but its not applicable here... Please read the quote from Section 2.6 of the IG above again. Host A is in the COOKIE-ECHOED state. C is trying to add the new address "C" to the TCB in the COOKIE-ECHOED state. The quote from the IG 2.6 above tells Host A to send the abort with the specified error code. > > > > > | | | > > |T1-cookie timeout | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > | . | | > > | . | | > > | . | | > > | | | > > > >Following IG Section 2.6 provides for DoS attack with spoofed > >addresses in address list. > > > >Host X can refuse access to A for an arbitrary number of multi-homed > >hosts, should A form an association with X. > > > > > So here, you are just illustrating (if you let the cookie-ack go from > X) a camped-on address scenario.. other than that, you have > a collision case.. and again having a auditing mechanism for > this case may be worthwhile... aka the HB of suspect > associations... at startup... X is not in the ESTABLISHED state. It is in the COOKIE-ECHOED state and never makes it to the ESTABLISHED state. I don't think HEARTBEATS can be sent in the COOKIE-ECHOED state, can they? Please look again at the above. --brian > > > But this next case is the "new" one worth looking at... > > >Here is a reverse hijack: > > > >Host A/B Host X Host C > > | | | > > |INIT A:1000 -> X:1000 | | > > |---------------------------------------------->| | > > |TCB1: | | > > |VT: X | | > > |PT: 0 | | > > |Loc: A:1000 | | > > |Rem: X:1000 | | > > |State: COOKIE-WAIT | | > > | | | > > | INIT-ACK X:1000 -> A:1000 (C)| | > > |<----------------------------------------------| | > > |(TCB1 is found) | | > > | | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > |TCB1: | | > > |VT: X | | > > |PT: W | | > > |Loc: A:1000 | | > > |Rem: X:1000, C:1000 | | > > |State: COOKIE-ECHOED | | > > | X does not | | > > | send (or delays) | > > | COOKIE-ACK | | > > > > So the association is not fully formed and you are in > COOKIE-ECHOED state.. not established... > > > | | | > > |T1-cookie timeout | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > | | | > > |T1-cookie timeout | | > > |COOKIE-ECHO A:1000->X:1000 | | > > |---------------------------------------------->| | > > | . | | > > | . | | > > | . | | > > | | | > > | INIT (IT: Y) C:1000 -> A:1000| > > |<-------------------------------------------------------| > > | | | > > > And I believe RFC2960 states: > " > For an endpoint that is in the COOKIE-ECHOED state it MUST populate > its Tie-Tags with the Tag information of itself and its peer (see > section 5.2.2 for a description of the Tie-Tags). > " > > > |INIT-ACK (IT: X, no tie tags) | | > > |------------------------------------------------------->| > > | | | > > | COOKIE-ECHO C:1000 -> A:1000 | > > |<-------------------------------------------------------| > > |Action B | | > > > So you would have tie-tags... But I still think you would > end at action B.. > > > |COOKIE-ACK A:1000 -> C:1000 | | > > |------------------------------------------------------->| > > |TCB1 | | > > |VT: X | | > > |PT: Y | | > > |Loc: A:1000 | | > > |Rem: X:1000, C:1000 | | > > |State: ESTABLISHED | | > > > > > And here is where you make a mistake.. and maybe because action-b's > wording needs some updates. > > When the COOKIE-ECHO arrives and you take Action-B you would > update your address list with only those addresses in the COOKIE. > So your association would NOT include X. And of course you > have two TCB and would need to collapse one of them... this > again is where possibly having a special "hold" state to see > who is who may be warrented... but, curently, the way our > implementation works.. the other assocation (the one with > X) would get aborted at least internally... and the other > would hold VT's X/Y but the Address X would NOT be > a part of the association... Ok, so if you kick X out of the TCB, then X still has the VT. It think it would be wise to require or strongly recommend that the TCB be reduced in such a way that X gets kicked out. > so if X did send in the > a message it would be rejected... since X does not belong > to the association.. no matter if the Vtag is correct or > not... Sending an ABORT with the VT is simple, X just spoofs C as the source address in the ABORT and uses VT:X as the verification tag. X can also send HEARTBEATs to A spoofed from C with the proper VT. A will dutifully send the HEARTBEAT-ACK with arbitrary contents of the hb_info to C. As X has the VT, some ADD-IP attacks or PR-SCTP attacks might be possible. Sending SACKs or DATA to A spoofed from C with the proper VT could have some interesting effects, because X also knows the A's initial TSN. Sending DATA with a TSN skipping large blocks of TSN number to A spoofed from C would canse A to send a pretty weird GAP report to C that could hang many associations or have them fail mysteriously. I think it would be best not to give X the VT of the association. Would it cause problems to treat COOKIE-ECHOED the same as ESTABLISHED? I don't see much difference between the restart actions (Action A) and collision action (Action B) for the COOKIE-ECHOED state? This would select a new IT and the VT would not be surrendered in this fashion? Maybe that would not work... But some solution that secures the VT is necessary. Could we say that if there are fewer addresses (we actually kick an address out of the TCB) that we choose a new IT? That would protect the VT in this case. --brian > > > > R > > >X now knows A's verification tag for its association with C. > >X can know that the association is established with C because > >COOKIE-ECHOs stop prematurely, or if A does not kick X out of > >the TCB (not stated in RFC or IG), a DATA or HEARTBEAT will > >eventually tell X that it is in the established state. DATA > >or a HEARTBEAT would also tell X C's verification tag for the > >association. Or, if X is not kicked out of the TCB, it could > >send an INIT and read C's verification tag out of the tie tags > >in the cookie in the INIT-ACK. > > > >If X is not kicked out of the TCB then one-way > >eavesdropping is possible. > > > > | | | > > |DATA (VT: Y) | | > > |---------------------------------------------->|------->| > > | | | > > > >Even if X is kicked out of the TCB, X knows A's verification tag > >for the association between A and C. A simultaneous attack on > >C could yeild C's verification tag for the association. > > > >A DoS attack would be to send an ABORT to A with the known VT > >when the COOKE-ECHO is not received, and start the process again > >with a new INIT. This DoS attack has the difference over the > >previous one that no ERROR message is sent to C. > > > >To avoid this problem, INIT received in the COOKIE-ECHO state > >needs to be treated the same as INIT in the ESTABLISHED state > >(new verification tag chosen), or COOKIE-WAIT (sent to X or > >known address of X). The former is preferrable because it > >does not cause a new denial of service attack. > > > >Closing this latter vulnerability also removes the need to find > >the existing TCB in the COOKIE-ECHO state based on the source > >address list, because a new IT is generated and no tie tags > >populated. > > > >--brian > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-2.cisco.com Tue Mar 11 17:22:50 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15301 for ; Tue, 11 Mar 2003 17:22:49 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2BMJZEY022048; Tue, 11 Mar 2003 14:19:36 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEK32535; Tue, 11 Mar 2003 14:19:34 -0800 (PST) Message-ID: <3E6E60F5.90805@cisco.com> Date: Tue, 11 Mar 2003 16:19:33 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030311045000.B8489@openss7.org> <3E6DE78F.2010603@cisco.com> <20030311140645.B19001@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: > > >> >> > >Please read the quote from Section 2.6 of the IG above again. Host >A is in the COOKIE-ECHOED state. C is trying to add the new address >"C" to the TCB in the COOKIE-ECHOED state. The quote from the IG 2.6 >above tells Host A to send the abort with the specified error code. > > > Interesting.. this is a mistake in the IG then.. if you read it literally you would only send the abort/error in the COOKIE-ECHOED state.. which is wrong.. it should be under the existing association.. aka ESTABLISHED. Not sure why its in the COOKIE-ECHOED state... We will fix this in the next IG pass... I will respond to the rest of your email seperately.. R >> >> > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Tue Mar 11 17:50:36 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16100 for ; Tue, 11 Mar 2003 17:50:34 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2BMmFhs002473; Tue, 11 Mar 2003 14:48:15 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEK36975; Tue, 11 Mar 2003 14:48:13 -0800 (PST) Message-ID: <3E6E67AD.4010805@cisco.com> Date: Tue, 11 Mar 2003 16:48:13 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030311045000.B8489@openss7.org> <3E6DE78F.2010603@cisco.com> <20030311140645.B19001@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: > > > > >>But this next case is the "new" one worth looking at... >> >> >> >>>Here is a reverse hijack: >>> >>>Host A/B Host X Host C >>> | | | >>> |INIT A:1000 -> X:1000 | | >>> |---------------------------------------------->| | >>> |TCB1: | | >>> |VT: X | | >>> |PT: 0 | | >>> |Loc: A:1000 | | >>> |Rem: X:1000 | | >>> |State: COOKIE-WAIT | | >>> | | | >>> | INIT-ACK X:1000 -> A:1000 (C)| | >>> |<----------------------------------------------| | >>> |(TCB1 is found) | | >>> | | | >>> |COOKIE-ECHO A:1000->X:1000 | | >>> |---------------------------------------------->| | >>> |TCB1: | | >>> |VT: X | | >>> |PT: W | | >>> |Loc: A:1000 | | >>> |Rem: X:1000, C:1000 | | >>> |State: COOKIE-ECHOED | | >>> | X does not | | >>> | send (or delays) | >>> | COOKIE-ACK | | >>> >>> >>> >>So the association is not fully formed and you are in >>COOKIE-ECHOED state.. not established... >> >> >> >>> | | | >>> |T1-cookie timeout | | >>> |COOKIE-ECHO A:1000->X:1000 | | >>> |---------------------------------------------->| | >>> | | | >>> |T1-cookie timeout | | >>> |COOKIE-ECHO A:1000->X:1000 | | >>> |---------------------------------------------->| | >>> | . | | >>> | . | | >>> | . | | >>> | | | >>> | INIT (IT: Y) C:1000 -> A:1000| >>> |<-------------------------------------------------------| >>> | | | >>> >>> >>> >>And I believe RFC2960 states: >>" >> For an endpoint that is in the COOKIE-ECHOED state it MUST populate >> its Tie-Tags with the Tag information of itself and its peer (see >> section 5.2.2 for a description of the Tie-Tags). >>" >> >> >> >>> |INIT-ACK (IT: X, no tie tags) | | >>> |------------------------------------------------------->| >>> | | | >>> | COOKIE-ECHO C:1000 -> A:1000 | >>> |<-------------------------------------------------------| >>> |Action B | | >>> >>> >>> >>So you would have tie-tags... But I still think you would >>end at action B.. >> >> >> >>> |COOKIE-ACK A:1000 -> C:1000 | | >>> |------------------------------------------------------->| >>> |TCB1 | | >>> |VT: X | | >>> |PT: Y | | >>> |Loc: A:1000 | | >>> |Rem: X:1000, C:1000 | | >>> |State: ESTABLISHED | | >>> >>> >>> >>> >>And here is where you make a mistake.. and maybe because action-b's >>wording needs some updates. >> >>When the COOKIE-ECHO arrives and you take Action-B you would >>update your address list with only those addresses in the COOKIE. >>So your association would NOT include X. And of course you >>have two TCB and would need to collapse one of them... this >>again is where possibly having a special "hold" state to see >>who is who may be warrented... but, curently, the way our >>implementation works.. the other assocation (the one with >>X) would get aborted at least internally... and the other >>would hold VT's X/Y but the Address X would NOT be >>a part of the association... >> >> > >Ok, so if you kick X out of the TCB, then X still has the >VT. It think it would be wise to require or strongly >recommend that the TCB be reduced in such a way that X gets >kicked out. > > As Ivan and I both stated.. this is what is intended, and we need to beef up all the collision cases with this notation that you must update all addresses etc.. more grist for the IG (as Ivan and I both stated)... In fact, thinking on this case a bit more.. it might be wise in this case to send a INIT and yourself "restart"... You know from the matching of addresses that you had a collision set of associations.. and thus you know things are amiss. But of course this comes back to the passive-agressive server case.. i.e. you contacted X in the first place, you obviously wanted something from X... so talking to C might not be what you want now... Before we worry about this case I think we need Mr. Bellovin's advise as to if this situation warrents attention... (as I have stated in other emails)... it is an interesting case.. though far-fetched... as Caitlin and Ivan have all said... > > >>so if X did send in the >>a message it would be rejected... since X does not belong >>to the association.. no matter if the Vtag is correct or >>not... >> >> > >Sending an ABORT with the VT is simple, X just spoofs C as the >source address in the ABORT and uses VT:X as the verification >tag. > > Hmm. that may be, as long as ingress filtering is not in place.. which most all ISP's have now done.. it is much more difficult to spoof IP addresses these days... >X can also send HEARTBEATs to A spoofed from C with the proper >VT. A will dutifully send the HEARTBEAT-ACK with arbitrary >contents of the hb_info to C. As X has the VT, some ADD-IP >attacks or PR-SCTP attacks might be possible. Sending SACKs or >DATA to A spoofed from C with the proper VT could have some >interesting effects, because X also knows the A's initial TSN. >Sending DATA with a TSN skipping large blocks of TSN number to A >spoofed from C would canse A to send a pretty weird GAP report >to C that could hang many associations or have them fail >mysteriously. > This all comes down to the passive-agressive server case... you seem hung on this case.. If Steve Bellovin thinks this case needs attention there are some steps that can be taken.. since you matched addresses when all of this occured you know there is a problem.. a number of solutions can be found: 1) Abort both, and let the apps restart 2) Prune out the one (as we mention above) and then put it into a restart mode.. aka send a INIT and start it with a new VT.. 3) And of course some proving of the addresses as well. Of course all of this depends on being able to detect up front that it is occuring when the INIT from C arrives... which can only be done if you match addresses inside the INIT. I will not discuss further any "passive/agressive" server case until after the IETF.. if Steve thinks it is not a worry then I see no reason to wring our hands and be concerned... on the other hand if not, we will probably go back through and flesh out the sketch we have of how to fix this.. The key of course will be early detection using the address lists... > >I think it would be best not to give X the VT of the >association. > >Would it cause problems to treat COOKIE-ECHOED the same as >ESTABLISHED? I don't see much difference between the restart >actions (Action A) and collision action (Action B) for the >COOKIE-ECHOED state? This would select a new IT and the VT >would not be surrendered in this fashion? > I would need to think on this.. there are a couple of scenarios that would break I am thinking... >Maybe that would >not work... But some solution that secures the VT is necessary. >Could we say that if there are fewer addresses (we actually >kick an address out of the TCB) that we choose a new IT? >That would protect the VT in this case. > I think this is about right.. if this is a concern .. then we want the side that recognizes an address left the association to send out a new INIT with new VT... to the address set.. this will then make the association restart before it ever gets up... but thats ok.. we will also need to have an "audit/list" scenario where we HB all suspect addresses in the various Passive/Agressive server cases... but those we will need to wait to fully flesh out.. R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Tue Mar 11 22:59:14 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25185 for ; Tue, 11 Mar 2003 22:59:11 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2C3u50E007604 for ; Tue, 11 Mar 2003 19:56:06 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2C3tMHb018654 for ; Tue, 11 Mar 2003 19:55:22 -0800 (PST) Received: from out003.verizon.net (out003pub.verizon.net [206.46.170.103]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2C3tqTP014787 for ; Tue, 11 Mar 2003 19:55:53 -0800 (PST) Received: from duck ([67.212.85.166]) by out003.verizon.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030312032924.GRSC3697.out003.verizon.net@duck> for ; Tue, 11 Mar 2003 21:29:24 -0600 Message-ID: <4123-2200333123339100@duck> Organization: Market*Access Int'l From: "David Dickson" To: "SCTP-IMPL@EXTERNAL.CISCO.COM" Subject: Homeland Defense - LA, San Fran, Phila - April 03 New speakers R&D Opportunities Date: Tue, 11 Mar 2003 22:33:09 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [67.212.85.166] at Tue, 11 Mar 2003 21:27:29 -0600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA25185 To: SCTP-IMPL@EXTERNAL.CISCO.COM Homeland Defense Training Conference Forecast and Budget Outlook And Grants Workshops With special tracks addressing... * Forecast and Budget Outlook (All cities) * Grants Workshop with expanded proposal tips and grants ID techniques (All cities) * Bio-Terrorism (San Fran and Philadelphia) * Corporate Risk Mitigation - Protecting the Directors and Officers (Los Angeles) * R&D Business Opportunities (Los Angeles) **** Speakers are listed below. Call our Training Conference Hotline at 703-807-2027 for information about how to view the web site for this conference, on-line register and get additional information about other training conferences. **** Dates and Locations: April 3, 2003 - Omni Hotel, Los Angeles April 8, 2003 - Hyatt Regency, San Francisco April 10, 2003 - Philadelphia (Site to be announced) Time: 7:00 AM Registration Program Starts: 8:00 AM Wrap-up: 5:00 PM Continental Breakfast, Refreshments, Lunch included. Conference Program will begin at 8:00 AM. **** Hot line available: To view the most current list of speakers, topics, hotel arrangements and how to register on-line, call our conference hot line at 703-807-2027. This hot line is available 24 hours a day. Budget and Outlook -- Morning Session Federal agency and capital hill staff will present an overview of funding, budget, new legislation, plans for implementing homeland defense in 2003. Members of the new Department of Homeland Security have been invited. Names will be announced once confirmed. Speakers include: * FEMA * EPA * Department of Justice - FBI * Department of Justice - Office of Domestic Preparedness * National Guard - Civil Support Teams * Army * State Emergency Management Executives * State Government Grants Managers * Department of Health and Human Services * Food and Drug Administration * Department of Homeland Security - * Center for Disease Control Grants Workshop -- Afternoon Session -- Track 1 The Grants Workshop will provide the attendee with important information about federal agency plans for over $3 billion in grants to first responders for training, communications and outfitting. Attendees will learn where the funding is located, how to obtain, win grants and how to survive the audit process. Speakers will also address such subjects as writing grants, how grants are evaluated, key actions to undertake while preparing for release of the grant notice, how to prepare for the audit and compliance checks, and resources for tracking new grant releases. All workshop attendees will be given a free copy of the Homeland Defense Grants Database -- a $395 value. Speakers include: * First Responder Grants, FEMA * Justice Office of Domestic Preparedness Grants * Michael Paddock, President, Grants Office LLC. (Mr. Paddock will chair the Grants Workshop, proposal writing and grants opportunity identification workshop) * Stephen M. Sorett, Partner, Reed Smith, Washington, D.C. (Nationally recognized Grants law specialist) * Christopher L. Rissetto, Partner, Reed Smith, Washington, D.C. (Nationally recognized Grants law specialist) Bio- Terrorism Response -- Afternoon Session -- Track 2 (San Francisco and Philadelphia only) The speakers will represent DoD, federal and state agency personnel who will present agency plans, programs, new initiatives aimed at developing key technologies and products in support to homeland defense and homeland security as they relate to bio-terrorism. Opportunities to be covered include bio-technology, R&D and supporting technologies. Case studies, best practices and lessons-learned will be featured. Names will be posted at this web site when confirmed. *** Call our Conference Information Hot Line at 703-807-2027 for more information. Risk Minimization and Avoidance for Government and Corporate Executives -- Track Two (Los Angeles) This track will examine practical safeguards that should be considered by government and industry with respect to risk mitigation, continuity of operations, and business planning. Topics include: * Vulnerability Assessments * Site Safety and Security * Facility Structural Evaluation * Blast, Explosion and Impact Analysis * Chemical, Biological and Radiological Threats * Facility Protection * Emergency Planning, Crisis Management and Crisis Recovery * Cyber Security About this conference This administration will direct billions of dollars through federal and state agencies with the goal of improving America's ability to detect, respond, recover and reconstitute from terrorist attacks. Many of these improvements will directly assist state and local leaders as they also respond to national disasters and major industrial accidents. Funding will include pending funds from the First Responder Initiative now before congress. This $3.5 billion dollar initiative will be focused at state and local needs for communications, emergency medical and first responders. America's 3,000 counties and 18,000 cities all have varying needs and requirements based on infrastructure and threat. This conference will examine the development of strategies, requirements, solutions and plans at the regional, state and local levels. Federal agency support programs will also be examined. Other topics include: * Report on federal and state grants to support homeland defense initiatives * Grants workshop with tips, tools, lessons-learned * Report from Capital Hill on pending legislation, funding and new programs * Federal agency reports on roles at regional, state and local levels Who Should Attend * Regional, state and local emergency management executives and senior staff * Federal and DoD managers with an assigned mission in homeland defense * Industry executives with products and services that support homeland defense * Trainers and instructors in emergency response * State and local grants staff interested in updating their understanding of available grants and grants application techniques Exhibitors may include: * IT security, command centers, database solutions, information sharing * Mobile communications * Perimeter security * Personnel security * Security planners and consultants * Outfitting emergency response teams * Federal systems integrators * Personal protective equipment * Bio-terrorism planning, response, and strategies * ... and many others. What you will learn: * What are the programs and funding sources and their outlook * New products in development and on the drawing boards * Special needs and requirements for outfitting * New initiatives being planned at the federal, state and local levels * The role of grants in funding local needs * Civil agency organization and planning * Legislative initiatives that are expected to determine new programs and funding sources * How to write your grants proposal * Strategies to prepare for grants audits and compliance checks. HEAR WHAT OTHERS HAVE SAID ABOUT THE TWO PREVIOUS TRAINING CONFERENCES IN THIS SERIES IN JAN AND FEB OF THIS YEAR... - Hi Don: Your organization did a great job putting together the conference on Feb. 6 in Washington. J.S./Organizational and Grants Development - Great job. Very substantive. High value. Thanks. (Federal agency division chief) - MarketAccess has put together some of the best programs out there today. I found this Jan 2003 homeland conference substantive, diverse, and informative. (Pres. and CEO). - Networking opportunities were very useful. (County Admin. Officer) - A very well organized, professional program. (Vice president) - Excellent workshop. Diverse cross section of speakers. Workshop was organized in a very effective format. (County Sheriff ) - Filled with information that can be used by Sheriff's office. (Deputy Sheriff ) - Excellent staff and services. Presentations were clear and concise. Timetable kept very well. Excellent information presented on grants. (Chief of Police ) - Should be held annually. Very good information. (DoD Captain ) - Excellent conference. Met the objectives. (COO ) - Great location. Great job. Will recommend to others. (County IT Manager.) About the Speakers Michael Paddock CEO Grants Office, LLC Michael Paddock has been in the business of grant seeking since 1993. A graduate of Syracuse University, he has consulted with dozens of organizations and municipalities in the Northeast US and the District of Columbia. He is an active member of the US Interagency Electronic Grants Committee's State and Local Subcommittee, and he helped found the New York State E-Grants Project, on which he serves as a convening member. Christopher L. Rissetto Partner, Government Contracts & Export Compliance Group Christopher L. Rissetto practices in the areas of grants and infrastructure, including environmental law, government contracting, infrastructure development and appropriations legislation. His practice emphasizes the Clean Water Act, government contracts and other environmental law, such as Superfund, the Safe Drinking Water Act, the Clean Air Act, and other public works legislation. Additionally, he counsels clients on transportation issues including the Intermodal Surface Transportation Efficiency Act of 1992 and other transportation grant programs, including the FAA. Mr. Rissetto's practice involves representation of large and small municipal clients and private corporations. He is highly educated and informed in many areas, including Clean Water Act regulatory programs, including EPA construction grants audits, NPDES permit strategy, pretreatment, and enforcement defense, wetlands permitting by EPA and the Corps of Engineers, Superfund, hazardous waste cleanup contracting, and related procurement, bid protest, construction claims, suspension and debarment, legislation, and litigation. Mr. Rissetto also practices in grant programs of other agencies, including the U.S. Agriculture, Commerce and Justice Departments. Stephen M. Sorett Partner, Government Contracts Group Stephen M. Sorett is an attorney in the Washington, D.C. office of Reed Smith who focuses on all phases of government contracting with an emphasis on outsourcing, privatization, and project finance transactions. For many years he has dealt with all aspects of the public contracting process at all levels of government, and his experience includes contract formation, administration, claims, and audit resolution; and in the past few years has worked extensively with companies and governments in the emerging field of electronic commerce including Business-to-Business and Business-to-Government transactions. ... Other speakers are being confirmed now. Call our Conference Hot Line at 703-807-2027 to find out how to register on line, view the most current agenda and obtain information about the conference, hotel and topics. SPONSORS * The Law Firm of Reed Smith * Symantec * Alvarion Broadband Wireless * Contingency Planning and Management On-Line * Disaster Recovery Institute, International * Homeland Defense Journal, Inc. * INPUT * Department of Transportation, TASC * Wireless Communications Association, International * Grants Office, LLC * NEXTEL * Perseus Development Corporation * Information Builders *** Be a Sponsor -- Exhibitor to Showcase your Products and Services. For information on how you can exhibit and participate as a sponsor, contact Cara Lombardi at 703-807-2743. Registration Fee * Industry Credit Card or Check in Advance $695 * Small business (Less than 100 people) $595 * Government Credit Card, Check, Training Form or Invoice $445 Conference Registration Options * Fax the Registration form at the end of this message to 703-807-2728. * Call Parrish Knight at 703-807-2748 * Call our Training Conference Hot Line at 703-807-2027 and get instructions on how you can register on line, view the current list of speakers and agenda. To request more information: Call 703-807-2748. Marketing, Conference Management and Production by: Market*Access International, Inc. (301) 455-5633 **** REGISTRATION FORM **** Homeland Defense - Outlook and Grants Conference Registration Form SELECT WHICH CONFERENCE YOU ARE REGISTERING FOR... IMPORTANT ( ) April 3, 2003 - LA ( ) April 8, 2003 - San Francisco ( ) April 10, 2003 - Philadelphia (Use additional pages as needed for multiple employees) Attendee Name: Title: Company/Agency: Address: City: State: Zip Code: Email: Telephone: Fax: Note: Payment requested in advance. Please check one of the following as your form of payment: [ ] Check Make checks payable to: Market*Access International Send to: Market*Access, 4301 Wilson Blvd. #1003, Arlington, VA 22203 [ ] VISA [ ] MasterCard [ ] American Express Account Number: ___________________________Exp. Date___________________ Cardholder Name: ______________________________________________________ Signature (required) or telephone order Course Fees: * Industry Credit Card or Check in Advance $695 * Small business (Less than 100 people) $595 * Government Credit Card, Check, Training Form or Invoice $445 Registration and Information: Call Parrish Knight, (703) 807-2748 Fax this form to (703) 807-2728. Thank you. For more information about specific speakers and agendas, call our training conference hot line at 703-807-2027 or Parrish Knight at 703-807-2748. *************** SPEAKER INFORMATION ************************** (All invited. Most confirmed or confirming) The (New) Department of Homeland Security, Wash. DC will send senior representative to speak at all conferences. (Confirmed) The Department of Justice, Office of Domestic Preparedness, will have senior representative to speak at all conferences. (Confirmed) April 3--Los Angeles Rear Admiral Stone, Director, J4 Logistics, NORTHCOM John Carney, Manager, Pathogen Countermeasures Program, DARPA Kate Henderson, Program Manager, ODP, US DOJ Payton Smith, Manager, Public Sector Market Analysis Services, INPUT Speaker TBD, Corning Stan Z. Soloway, President, Professional Services Council Speaker TBD, Governor's Office on Service and Volunteerism Rod Mateer, Partner, Deloitte & Touche Jim D'Agostino, Reed Smith LLP (R&D Keynote for Governement) Speakers TBD, Lawrence Livermore Charles F. Cleland, Ph.D, Director, SBIR Program, USDA/CSREES Clark Kelso, California State Chief Information Officer, Department of Finance, Technology Oversight & Security Unit Terry Hawkins, Los Alamos National Laboratories, Center For Homeland Security Governor Gray Davis George Vinson, Special Advisor on California Security Senator Feinstein Congresswoman Jane Harman, Head of House Subcommittee on Terrorism and Homeland Security Speaker TBD, RISS Nancy Ward, National Preparedness Director FEMA (Region 9 Steve Boranian, Reed Smith, Safety Act Major Daniel Webber, Commander, 9th WMD CST Larry Kessler, Head of FDA Labs, FDA Alex Azar, DHHS Laurene Mascola, Chief of Communicable Disease Control Program, County of LA Dept of Health Services Franci Wise, Director of Acute Communicable Disease, Contra Costa County Dept of Public Health Jayson Ahern, Assistant Commissioner, Office of Field Operations, United States Customs Bruce C. Thompson, Regional Administrator (Region IX), SBA Dennis Pinkard, Assistant to the Director of Homeland Security at SPAWAR, Space and Naval Warfare Systems, U.S. Alonza E. Cruse, District Director, Los Angeles District Office, FDA Anthony S. Fauci, MD, Director, National Institute of Allergy and Infectious Diseases, National Institutes of Health Michael Amado, Director of Emergency Services, Red Cross Bernard Wilson, Chief of Airport Police * Other speakers being invited and confirmed... ************************* April 8--San Francisco Kathleen Steinle, Region X Program Manager , Office for Domestic Preparedness, US DOJ Payton Smith, Manager, Public Sector Market Analysis Services, INPUT Alan Chvotkin, Sr. VP./Counsel, Professional Services Council Speaker TBD, Speaker TBD, Governor's Office on Service and Volunteerism Rod Mateer, Partner , Deloitte & Touche Speaker TBD, Corning Mayor Willie Brown, San Francisco Jayson Ahern, Assistant Commissioner, Office of Field Operations, United States Customs Dennis Pinkard, Assistant to the Director of Homeland Security at SPAWAR, Space and Naval Warfare Systems, U.S. Major Daniel Webber, Commander, 9th WMD CST Nancy Ward, National Preparedness Director, FEMA (Region 9) Regional Administrator, FEMA (Region 9) Dennis Linsley, District Director, San Francisco District Office , FDA John Conte Director, Hospital and Infection Control, UCSF * Other speakers being invited and confirmed... **************************************************** April 10--Philadelphia Lt. Col Xavier Stewart, Commander, 3rd WMD CST, Pennsylvania National Guard Mark Dozier, Program Manager, ODP, US DOJ Speaker TBD, Office of Terrorism Preparedness & Emergency Response, Centers For Disease Control Jay Keough, Vice President, Industrial Hygiene/Environmental Safety, BBL Inc. Stan Soloway, President, Professional Services Council Mr. Moshe Levy, Former Chief of Staff, Israeli Armed Froces, Safeguards Tech, Inc. Dr. Harvey Rubin, M.D., Ph.D., Director, Institute for Strategic Threat Analysis and Response, University of Pennsylvania David Sanka, PA Emergency Management Agency Jim D'Agostino, Reed Smith LLP Rod Mateer, Partner, Deloitte & Touche Mr. Sid Casperson, Director of the New Jersey Office of Counter-Terrorism The Honorable John Burzichelli, Assemblyman, Legislative District 3 of the State of New Jersey, Legislative Committee Member, Homeland Security & State Preparedness, Mayor of Paulsboro, New Jersey Dr. Penrose (Parney) Albright Assistant Director for Homeland and National Security in the Office of Science and Technology Policy, and Senior Director for Research and Development in the Office of Homeland Security of the Executive Office of the President Governor Edward G. Rendell Donald S. Welsh, Regional Administrator, Region 3, EPA Mr. Jamie Turner, Director, Deleware Emergency Management Patricia G. Arcuri, Acting Regional Director, FEMA, Region 3 Marilyn Cordell, NY State Office for Technology If you wish to be REMOVED from this list, please REPLY and place REMOVE in the SUBJECT line. From owner-extdom.sctp-impl@sj-core-1.cisco.com Wed Mar 12 04:54:07 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27535 for ; Wed, 12 Mar 2003 04:54:06 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2C9ox0E018686 for ; Wed, 12 Mar 2003 01:51:00 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2C9p0gD028865 for ; Wed, 12 Mar 2003 01:51:01 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2C9ooTP015680 for ; Wed, 12 Mar 2003 01:50:51 -0800 (PST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2C9NI100234 for ; Wed, 12 Mar 2003 11:23:18 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 11:24:39 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 11:24:39 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 11:24:39 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 11:24:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Wed, 12 Mar 2003 11:24:38 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLoHGGn7QFfztP1QHe7QfuPSuUQBAAV5UkA From: To: , Cc: , X-OriginalArrivalTime: 12 Mar 2003 09:24:38.0992 (UTC) FILETIME=[3489AD00:01C2E879] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA27535 Randall, Brian, > Brian F. G. Bidulock wrote: > > > > > > >> > >> > > > >Please read the quote from Section 2.6 of the IG above again. Host > >A is in the COOKIE-ECHOED state. C is trying to add the new address > >"C" to the TCB in the COOKIE-ECHOED state. The quote from the IG 2.6 > >above tells Host A to send the abort with the specified error code. > > > > > > > > Interesting.. this is a mistake in the IG then.. if you read it > literally you > would only send the abort/error in the COOKIE-ECHOED state.. which > is wrong.. it should be under the existing association.. aka > ESTABLISHED. > > Not sure why its in the COOKIE-ECHOED state... > > We will fix this in the next IG pass... > > I will respond to the rest of your email seperately.. > > R But then... Let's see... If you are an attacker and you more or less know that some other peer is going to connect to a server, you can send INITs to the peer, including the addresses of the server... You send some of them, and you will receive INIT ACKs with random ITs... In the moment the peer tries to connect to the server, if we are sending quite many INITs, we could hit twice the peer while in the COOKIE WAIT and/or COOKIE ECHO. This will mean that suddenly you will receive two consecutive INIT ACKs with the same IT, meaning that the peer is trying to connect to the server (I don't feel like making a drawing, but I hope it is clear enough)... At this point, you know the VT that the server will use to send packets to the peer. So you can try something nasty... Of course, you will either know quite precisely the time when the peer is going to connect to the server, or be prepared to send many INITs... Summarizing, if you do send the INIT ACK back, I guess you will have to do it to any of the "known addresses"... BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-core-5.cisco.com Wed Mar 12 05:55:48 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28998 for ; Wed, 12 Mar 2003 05:55:46 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2CArIhs013013 for ; Wed, 12 Mar 2003 02:53:19 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2CAqYh5015731 for ; Wed, 12 Mar 2003 02:52:34 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2CAr6TP010667 for ; Wed, 12 Mar 2003 02:53:07 -0800 (PST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CAPO101394 for ; Wed, 12 Mar 2003 12:25:24 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 12:26:45 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 12:26:45 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 12:26:44 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 12:26:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Wed, 12 Mar 2003 12:26:43 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLoIFW7O3CZgTjVSbic0DK8ykv+WAAXg1mA From: To: , Cc: , X-OriginalArrivalTime: 12 Mar 2003 10:26:44.0248 (UTC) FILETIME=[E0F6A180:01C2E881] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA28998 Randall, Brian, ... snip... > >Ok, so if you kick X out of the TCB, then X still has the > >VT. It think it would be wise to require or strongly > >recommend that the TCB be reduced in such a way that X gets > >kicked out. > > > > > As Ivan and I both stated.. this is what is intended, and we need > to beef up all the collision cases with this notation that > you must update all addresses etc.. more grist for the > IG (as Ivan and I both stated)... > > > In fact, thinking on this case a bit more.. it might be wise in this > case to send a INIT and yourself "restart"... You know from the > matching of addresses that you had a collision set > of associations.. and thus you know things are > amiss. But of course this comes back to the > passive-agressive server case.. i.e. you contacted > X in the first place, you obviously wanted something > from X... so talking to C might not be what you want now... This is the problem... Most probably you want to be defensive with C, not with X... This scenario is the complete opposite to what one normally thinks it could be an attack... > Before we worry about this case I think we need Mr. Bellovin's > advise as to if this situation warrents attention... (as I have > stated in other emails)... it is an interesting case.. though > far-fetched... as Caitlin and Ivan have all said... > > > > > >>so if X did send in the > >>a message it would be rejected... since X does not belong > >>to the association.. no matter if the Vtag is correct or > >>not... > >> > >> > > > >Sending an ABORT with the VT is simple, X just spoofs C as the > >source address in the ABORT and uses VT:X as the verification > >tag. > > > > > Hmm. that may be, as long as ingress filtering is not in place.. which > most all ISP's have now done.. it is much more difficult to spoof > IP addresses these days... But, of course, it is still possible... > >X can also send HEARTBEATs to A spoofed from C with the proper > >VT. A will dutifully send the HEARTBEAT-ACK with arbitrary > >contents of the hb_info to C. As X has the VT, some ADD-IP > >attacks or PR-SCTP attacks might be possible. Sending SACKs or I'm not that sure about this... Because of that new abort defined in the AddIP draft I talked about... > >DATA to A spoofed from C with the proper VT could have some > >interesting effects, because X also knows the A's initial TSN. > >Sending DATA with a TSN skipping large blocks of TSN number to A > >spoofed from C would canse A to send a pretty weird GAP report > >to C that could hang many associations or have them fail > >mysteriously. > > > > This all comes down to the passive-agressive server case... you seem > hung on this case.. If Steve Bellovin thinks this case > needs attention there are some steps that can be taken.. since Exactly... I fail to see how somebody to who you connected, would like to attack you... Unless it is a "trusted" server, and somehow somebody manipulated it, but if somebody is able to do so, he will be able of worst things... > you matched addresses when all of this occured you know > there is a problem.. a number of solutions can be found: > > 1) Abort both, and let the apps restart I don't think this is a good idea... Think that the probable attacker is C, not X... > 2) Prune out the one (as we mention above) and then > put it into a restart mode.. aka send a INIT and start it > with a new VT.. > 3) And of course some proving of the addresses as well. > > Of course all of this depends on being able to detect > up front that it is occuring when the INIT from C arrives... which > can only be done if you match addresses inside the INIT. Right... > I will not discuss further any "passive/agressive" server case until > after the IETF.. if Steve thinks it is not a worry then I see > no reason to wring our hands and be concerned... on the > other hand if not, we will probably go back through and > flesh out the sketch we have of how to fix this.. > > The key of course will be early detection using the > address lists... > > > > > >I think it would be best not to give X the VT of the > >association. > > > >Would it cause problems to treat COOKIE-ECHOED the same as > >ESTABLISHED? I don't see much difference between the restart > >actions (Action A) and collision action (Action B) for the > >COOKIE-ECHOED state? This would select a new IT and the VT > >would not be surrendered in this fashion? > > > I would need to think on this.. there are a couple of scenarios > that would break I am thinking... > > >Maybe that would > >not work... But some solution that secures the VT is necessary. > >Could we say that if there are fewer addresses (we actually > >kick an address out of the TCB) that we choose a new IT? > >That would protect the VT in this case. > > > I think this is about right.. if this is a concern .. then we want > the side that recognizes an address left the association to send out > a new INIT with new VT... to the address set.. this will then > make the association restart before it ever gets up... but > thats ok.. we will also need to have an "audit/list" scenario > where we HB all suspect addresses in the various Passive/Agressive > server cases... but those we will need to wait to fully flesh > out.. I have took a look to scenarios where choosing a new IT when answering in the COOKIE ECHO state could be harmful... And so far it looked ok... If Steve says we should care about this, this might be one way of avoiding this agressive server situation... BR Iván Arias Rodríguez > > R > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > From owner-extdom.sctp-impl@sj-core-5.cisco.com Wed Mar 12 07:15:10 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01370 for ; Wed, 12 Mar 2003 07:15:08 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2CC8Uhs001981; Wed, 12 Mar 2003 04:08:31 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEK99645; Wed, 12 Mar 2003 04:08:29 -0800 (PST) Message-ID: <3E6F233D.6050409@cisco.com> Date: Wed, 12 Mar 2003 06:08:29 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: bidulock@openss7.org, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez@nokia.com wrote: > Randall, Brian, > > > >>Brian F. G. Bidulock wrote: >> >> >> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>Please read the quote from Section 2.6 of the IG above again. Host >>>A is in the COOKIE-ECHOED state. C is trying to add the new address >>>"C" to the TCB in the COOKIE-ECHOED state. The quote from the IG 2.6 >>>above tells Host A to send the abort with the specified error code. >>> >>> >>> >>> >>> >>Interesting.. this is a mistake in the IG then.. if you read it >>literally you >>would only send the abort/error in the COOKIE-ECHOED state.. which >>is wrong.. it should be under the existing association.. aka >>ESTABLISHED. >> >>Not sure why its in the COOKIE-ECHOED state... >> >>We will fix this in the next IG pass... >> >>I will respond to the rest of your email seperately.. >> >>R >> >> > > But then... Let's see... > > If you are an attacker and you more or less know that some other peer is going to connect to a server, you can send INITs to the peer, including the addresses of the server... > > You send some of them, and you will receive INIT ACKs with random ITs... In the moment the peer tries to connect to the server, if we are sending quite many INITs, we could hit twice the peer while in the COOKIE WAIT and/or COOKIE ECHO. This will mean that suddenly you will receive two consecutive INIT ACKs with the same IT, meaning that the peer is trying to connect to the server (I don't feel like making a drawing, but I hope it is clear enough)... At this point, you know the VT that the server will use to send packets to the peer. So you can try something nasty... > > Of course, you will either know quite precisely the time when the peer is going to connect to the server, or be prepared to send many INITs... > > Summarizing, if you do send the INIT ACK back, I guess you will have to do it to any of the "known addresses"... > > BR Iván Arias Rodríguez > > > Ahh, yes.. I knew last night that there was some reason we put COOKIE-ECHOED state in this.. but even at that, one important point (at least from my quick re-read of the section)... it does not say anything about the ESTABLISHED state.. Now of course if the correct action is to send an ABORT (with or without error-causes) then we should do that in COOKIE-ECHOED OR ESTABLISHED... right now if I read correctly last night.. it does not tell you to do this when you are in ESTABILISHED so then an attacker can gain the tags.... So we at least need to put wording in the IG to include the ESTABLISHED state as well. R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Wed Mar 12 07:41:55 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01801 for ; Wed, 12 Mar 2003 07:41:54 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2CCdhhs020113 for ; Wed, 12 Mar 2003 04:39:44 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2CCdX6U028994 for ; Wed, 12 Mar 2003 04:39:33 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h2CCbKwG013999 for ; Wed, 12 Mar 2003 04:37:22 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CCGUF11952 for ; Wed, 12 Mar 2003 14:16:30 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 14:12:57 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 14:12:57 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 14:12:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Wed, 12 Mar 2003 14:12:56 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLokDGJvtluu6ONSLiceaebNWoCSgAAChhg From: To: Cc: , , X-OriginalArrivalTime: 12 Mar 2003 12:12:56.0715 (UTC) FILETIME=[B73FEDB0:01C2E890] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA01801 > Ivan.Arias-Rodriguez@nokia.com wrote: > > > Randall, Brian, > > > > > > > >>Brian F. G. Bidulock wrote: > >> > >> > >> > >>> > >>> > >>> > >>> > >>>> > >>>> > >>>> > >>>> > >>>Please read the quote from Section 2.6 of the IG above again. Host > >>>A is in the COOKIE-ECHOED state. C is trying to add the > new address > >>>"C" to the TCB in the COOKIE-ECHOED state. The quote from > the IG 2.6 > >>>above tells Host A to send the abort with the specified error code. > >>> > >>> > >>> > >>> > >>> > >>Interesting.. this is a mistake in the IG then.. if you read it > >>literally you > >>would only send the abort/error in the COOKIE-ECHOED state.. which > >>is wrong.. it should be under the existing association.. aka > >>ESTABLISHED. > >> > >>Not sure why its in the COOKIE-ECHOED state... > >> > >>We will fix this in the next IG pass... > >> > >>I will respond to the rest of your email seperately.. > >> > >>R > >> > >> > > > > But then... Let's see... > > > > If you are an attacker and you more or less know that > some other peer is going to connect to a server, you can send > INITs to the peer, including the addresses of the server... > > > > You send some of them, and you will receive INIT ACKs > with random ITs... In the moment the peer tries to connect to > the server, if we are sending quite many INITs, we could hit > twice the peer while in the COOKIE WAIT and/or COOKIE ECHO. > This will mean that suddenly you will receive two consecutive > INIT ACKs with the same IT, meaning that the peer is trying > to connect to the server (I don't feel like making a drawing, > but I hope it is clear enough)... At this point, you know the > VT that the server will use to send packets to the peer. So > you can try something nasty... > > > > Of course, you will either know quite precisely the > time when the peer is going to connect to the server, or be > prepared to send many INITs... > > > > Summarizing, if you do send the INIT ACK back, I guess > you will have to do it to any of the "known addresses"... > > > > BR Iván Arias Rodríguez > > > > > > > Ahh, yes.. I knew last night that there was some reason we put > COOKIE-ECHOED state in this.. but even > at that, one important point (at least from my quick re-read of the > section)... it does not say anything > about the ESTABLISHED state.. Now of course if the correct > action is to > send an ABORT (with > or without error-causes) then we should do that in COOKIE-ECHOED OR > ESTABLISHED... right > now if I read correctly last night.. it does not tell you to do this > when you are in ESTABILISHED > so then an attacker can gain the tags.... Do you mean that the IG doesn't say that you have to send back an ABORT if you are in the ESTABLISHED state? It does... That's section 5.2.2 :-) The difference is that in the ESTABLISHED state you create a new IT, while in the COOKIE ECHO you use the previous one. BR Iván Arias Rodríguez > So we at least need to put wording in the IG to include the > ESTABLISHED > state as well. > > R > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > From owner-extdom.sctp-impl@sj-core-1.cisco.com Wed Mar 12 08:57:23 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03618 for ; Wed, 12 Mar 2003 08:57:21 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CDt00E021024; Wed, 12 Mar 2003 05:55:00 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEL04122; Wed, 12 Mar 2003 05:54:58 -0800 (PST) Message-ID: <3E6F3C31.2030203@cisco.com> Date: Wed, 12 Mar 2003 07:54:57 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: bidulock@openss7.org, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez@nokia.com wrote: > > > I have took a look to scenarios where choosing a new IT when answering in the COOKIE ECHO state could be harmful... And so far it looked ok... > > If Steve says we should care about this, this might be one way of avoiding this agressive server situation... > > BR Iván Arias Rodríguez > > > > > Ok, I looked into my book ... the drawings in there are nice to follow... :> and yes I see no problem as yet.. but lets consider this a minute (and I am feeling like drawing this am so here is the scenario A X /C? D/C? ================================================================= IT=Q -----A->0:INIT(A,IT=Q)->X--------------------------------------> Cookie-Wait state <--------------A:INIT-ACK(X,C,IT=Y)Y:COOKIE()->X---------------------------------> <---------------------------------------------------- scenario 1 ----------------------------------A->P:INIT-ACK(A,IT=Q')->D->---------------------------------------------> <2> scenario 2 ---------------------------------A->-ABORT(??error cause??)--D->------------------------------------> Now currently, I think we would do <2> .. Ias you validly pointed out.. we just need to expand it to include established :>) send an abort.. possibly with an Error Cause.. which we may want to get rid of or at least have "a MAY insert error cause" instead of the SHOULD thats there... and also note that this may give away information to an attacker. Now lets say we choose <1>, since we have a different set of addresses we can't really include tie-tags, otherwise we may be revealing the Tag of our forming assoc with X (which is the same reason in the restart case you can't send if the address set is not the same). So the only way to handle it is to update the TCB with the new choosen tag (Q').. but this means that you have choosen X as the bad guy... and that association is defunct... so when X sends <--------------<-A-Q:COOKIE-ACK()--<-X--------- It will be rejected since the tag does not match and silently discarded. Now X will eventually send a packet and retransmit until its association dies. More so, there is a fundamental question here... whom do you trust? The guy you contacted and want to talk to some guy that sends you a INIT... It could be that D does not have C but instead X has C. By doing anything like this it just introduces a much easier attack... I can get you to change the tag of a forming association by simply sending in an INIT... and thus get you to talk to me instead of the real peer you wish to talk to.. very bad... And thinking about not looking at the addresses (as is currently done in openss7's stack) you have a very bad situation. The RFC requires you to silently discard packets with the wrong vtag.. and NOT respond with an ABORT(). Without checking addresses this is not possible.. You hash to V-Tag/local-port... and you will always return NULL since you would not find an association that has the wrong V-Tag ... you get a null in this case when you lookup the association. Which means you send an ABORT() back to the guy.. So If I wish to attack such a stack what I do is start sending HB's (a rather innocent thing that could be from a previous assoc).... Attacker: Endpoint-A Src-Does_not_matter:V-Tag-guess-1:HB-----------------------------------> Lookup-Vtag() fails (we don't chk the address, and vtag is not matched). <---------------ABORT(No-TCB)----------------- Eventually you get Src-Does_not_matter:Luckey-guess:HB------------------------------------> Lookup-Vtag() find assoc <----------------HB-ACK--------------------------- Got Vtag. Now if Endpoint-A responds only to known addresses aka sends the HB back to its peers real address... no big deal.. do this enough and you now have an assurance that you have guessed a V-tag that someone is using.. Now the attacker can inject any data it wants into the associations tag that was guessed.. :-0 If you are looking up with address validation you get Attacker: Src-Does_matter:V-Tag-guess-1:HB------------------------------------------> No matter what the V-Tag is no src known so <-----------ABORT(No-TCB)------------------------------------ Here is the primary reason src addresses must be validated.. otherwise it not only weakens security of the V-tag it makes it so that anyone can figure out a V-Tag of an assocaition... its easy :-0 R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-2.cisco.com Wed Mar 12 09:26:22 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04259 for ; Wed, 12 Mar 2003 09:26:21 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2CEM7EY029531; Wed, 12 Mar 2003 06:22:08 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEL05605; Wed, 12 Mar 2003 06:22:06 -0800 (PST) Message-ID: <3E6F428D.50403@cisco.com> Date: Wed, 12 Mar 2003 08:22:05 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: bidulock@openss7.org, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez@nokia.com wrote: >> >> > Do you mean that the IG doesn't say that you have to send back an ABORT if you are in the ESTABLISHED state? > > It does... That's section 5.2.2 :-) > > The difference is that in the ESTABLISHED state you create a new IT, while in the COOKIE ECHO you use the previous one. > > BR Iván Arias Rodríguez > > > Ahh..more coffee and I have found it :> So then the only real issue is do we: 1) send ABORT()-> with error cause 2) send ABORT()-> with no error cause 3) send INIT-ACK to a known address or ??? I can see that <3> does reveal (indirectly) information to the attacker... since if you don't respond, and he/she does it enough, it can be assured that you do have a association up with some of the guessed addresses...Then it must do a 1 in 4billion guess for the Vtag... On the other hand sending an abort with an error cause sends the same information.. in fact probably it points out which addresses are valid :-0 So I wonder if <2> is not best, leave the optional error clause but warn that using it may reveal information to potential attackers.. or maybe just kill the cause... not sure... This is definetly a question for Steve... R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Wed Mar 12 10:17:17 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07206 for ; Wed, 12 Mar 2003 10:17:15 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2CFDihs009867 for ; Wed, 12 Mar 2003 07:13:44 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2CFD0Ye029392 for ; Wed, 12 Mar 2003 07:13:00 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2CFDqYX006427 for ; Wed, 12 Mar 2003 07:13:54 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CEmrF29837 for ; Wed, 12 Mar 2003 16:48:53 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 16:45:24 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 16:45:24 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 16:45:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Wed, 12 Mar 2003 16:45:23 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLonxHIXquf/2IeSwqed3S2qtx+jQAABVPw From: To: Cc: , , X-OriginalArrivalTime: 12 Mar 2003 14:45:23.0694 (UTC) FILETIME=[034628E0:01C2E8A6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA07206 > -----Original Message----- > From: ext Randall Stewart (cisco) [mailto:rrs@cisco.com] > Sent: Wednesday, 12 March, 2003 15:55 > To: Arias-Rodriguez Ivan (NRC/Helsinki) > Cc: bidulock@openss7.org; sctp-impl@external.cisco.com; cait@asomi.com > Subject: Re: Matching addresses in INIT and INIT ACK > > > Ivan.Arias-Rodriguez@nokia.com wrote: > > > > > > > I have took a look to scenarios where choosing a new IT > when answering in the COOKIE ECHO state could be harmful... > And so far it looked ok... > > > > If Steve says we should care about this, this might be > one way of avoiding this agressive server situation... > > > > BR Iván Arias Rodríguez > > > > > > > > > > > Ok, I looked into my book ... the drawings in there are nice > to follow... :> > and yes I see no problem as yet.. but lets consider this a > minute (and I am > feeling like drawing this am so here is the scenario > > A > > X /C? D/C? > ================================================================= > IT=Q > > -----A->0:INIT(A,IT=Q)->X---------------------------------------> > Cookie-Wait state > <-----------------------A:INIT-ACK(X,C,IT=Y) Cookie-echoed state > peer=X/C > ------------------A->Y:COOKIE()->X------------------------------> > > <---------------------------- <1> scenario 1 > > ------------------A->P:INIT-ACK(A,IT=Q')->D->-------------------> > > <2> scenario 2 > -----------------------A->-ABORT(??error cause??)--D->----------> > > Now currently, I think we would do <2> .. Ias you validly > pointed out.. > we just need > to expand it to include established :>) send an abort.. > possibly with an > Error Cause.. which > we may want to get rid of or at least have "a MAY insert > error cause" > instead of the SHOULD > thats there... and also note that this may give away > information to an > attacker. > > Now lets say we choose <1>, since we have a different set of > addresses > we can't really > include tie-tags, otherwise we may be revealing the Tag of > our forming > assoc with X (which > is the same reason in the restart case you can't send if the > address set > is not the same). > > So the only way to handle it is to update the TCB with the > new choosen > tag (Q').. but > this means that you have choosen X as the bad guy... and that Yes... If C continues with the establishment phase, at the end we will get a COOKIE ECHO with new VT but matching Tie Tags, so we do (A) and restart the association... > association is > defunct... so when X sends > > <--------------<-A-Q:COOKIE-ACK()--<-X--------- > > It will be rejected since the tag does not match and silently > discarded. In fact, it is an OOTB packet, but as per 8.4 7), you silently discard it... > Now X will > eventually send a packet and retransmit until its association dies. > > More so, there is a fundamental question here... whom do you trust? > > The guy you contacted and want to talk to some guy that sends > you a INIT... I think that trusting the guy you contacted is the wiser... > It could be that D does not have C but instead X has C. By > doing anything > like this it just introduces a much easier attack... I can get you to > change the tag of a forming association by simply sending in > an INIT... and thus get you to talk to me instead of the real peer > you wish to talk to.. very bad... This is basically the main reason the whole section 2.6 was written (but initially applied to the ESTABLISHED state, not the COOKIE ECHOED). I think that if you send the INIT ACK back to any shared address, instead of sending it to the source address of the INIT, you could avoid this... INIT ACK would go to the real owner of C in this case, no matter if it is host X/C of host D/C... If X/C is the impostor, then at the end D/C will get the control. If D/C is the attacker, then the INIT ACK sent to C will simply be discarded... I think this even works when the incoming INIT shares addresses with more than one association. You simply send the INIT ACK to ANY of the shared ones... If the INIT sender is not telling you the truth, this INIT ACK will go to another host with whom you have an association and will simply discard it (even if that other host were cheating you and that address is not his address, the INIT ACK will go nowhere, and it will be discarded (NOTE*)). If the INIT sender really owns that address, the INIT ACK will go to him, and he will take control over the association that before "owned" the address to which you sent the INIT ACK. That association was fake, so no problem about tearing it down when the new association comes up. But there is a problem, what about the other N associations that also shared addresses with this new one? You could think about sending HB to those addresses before establishing the new association, so you could verify them, but this could be a way of attacking you, since with a couple of packets sent it makes you send many HBs... HOWEVER, as soon as you receive any HB ACK back (take into account that you expect those HB to carry the peer's VT in the TCB for those older associations), you can assume that the new guy was in fact an attacker and simply tried to get more addresses than the ones he has... just one is enough to put a big red cross to the address that tried to cheat you (which you verified)... All this makes me think about another issue... You don't even need to verify all those addresses (or at least, one by one, since as soon as you receive a single valid HB ACK the game is over for the attacker and the verification process)... If you are smart enough to have a Boolean variable 'Address_Verified' for every peer address in your TCBs, this is not always necessary. This variable could be initially set to false for all the addresses (except the one to which you sent the INIT ACK), and be set to true when a HB (or DATA) chunk sent to that destination is acknowledged... When you are in this case about the attacker, if any of those addresses has the 'Address_Verified' set to true, you know the INIT sender is lying... otherwise, send a HB... Of course, when the address list only conflicts with a single association, this procedure is not needed... Just thinking... :-/ BR Iván Arias Rodríguez *NOTE: I think that I already pointed this out some long time ago (at least I have a note in my printed version of the RFC about this). OOTB packets that contain an INIT ACK should be silently discarded (same as COOKIE ACK), right? Section 8.4. of the RFC doesn't say anything about the INIT ACK case (but it does about the COOKIE ECHO case)... > And thinking about not looking at the addresses (as is currently > done in openss7's stack) you have a very bad situation. The RFC > requires you to silently discard packets with the wrong vtag.. and > NOT respond with an ABORT(). Without checking addresses this > is not possible.. > > You hash to V-Tag/local-port... and you will always return NULL > since you would not find an association that has the wrong V-Tag > ... you get a null in this case when you lookup the association. > Which means you send an ABORT() back to the guy.. > > So If I wish to attack such a stack what I do is start sending HB's (a > rather innocent thing that could be from a previous assoc).... > > Attacker: > > Endpoint-A > Src-Does_not_matter:V-Tag-guess-1:HB----------------------------> > > > Lookup-Vtag() fails (we don't chk the > > > address, and > vtag is not > matched). > > <---------------ABORT(No-TCB)----------------- > Eventually you get > Src-Does_not_matter:Luckey-guess:HB--------------------------- > ---------> > > > Lookup-Vtag() find assoc > > <----------------HB-ACK--------------------------- > Got Vtag. > > Now if Endpoint-A responds only to known addresses aka sends > the HB back to > its peers real address... no big deal.. do this enough and > you now have > an assurance > that you have guessed a V-tag that someone is using.. > > Now the attacker can inject any data it wants into the > associations tag that > was guessed.. :-0 > > If you are looking up with address validation you get > > Attacker: > Src-Does_matter:V-Tag-guess-1:HB---------------------------> > > > No matter what the V-Tag is no src known so > > <-----------ABORT(No-TCB)------------------------------------ > > > Here is the primary reason src addresses must be validated.. > otherwise > it not only weakens > security of the V-tag it makes it so that anyone can figure > out a V-Tag > of an assocaition... > its easy :-0 > > > > > R > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > From owner-extdom.sctp-impl@sj-core-5.cisco.com Wed Mar 12 10:27:13 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07792 for ; Wed, 12 Mar 2003 10:27:12 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2CFF9hs011027 for ; Wed, 12 Mar 2003 07:15:10 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2CFF9qd012884 for ; Wed, 12 Mar 2003 07:15:09 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h2CFD4Zi021474 for ; Wed, 12 Mar 2003 07:13:06 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CFEhF25256 for ; Wed, 12 Mar 2003 17:14:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 17:11:14 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 17:11:13 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 17:11:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Wed, 12 Mar 2003 17:11:12 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLootLdemB/a/EwR4OxJphO26i0mAABJa1w From: To: Cc: , , X-OriginalArrivalTime: 12 Mar 2003 15:11:13.0569 (UTC) FILETIME=[9F125110:01C2E8A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA07792 > >> > > Do you mean that the IG doesn't say that you have to > send back an ABORT if you are in the ESTABLISHED state? > > > > It does... That's section 5.2.2 :-) > > > > The difference is that in the ESTABLISHED state you > create a new IT, while in the COOKIE ECHO you use the previous one. > > > > BR Iván Arias Rodríguez > > > > > > > > Ahh..more coffee and I have found it :> > > So then the only real issue is do we: > > 1) send ABORT()-> with error cause > 2) send ABORT()-> with no error cause > 3) send INIT-ACK to a known address > > or ??? > > I can see that <3> does reveal (indirectly) information > to the attacker... since if you don't respond, and he/she > does it enough, it can be assured that you do have a > association up with some of the guessed addresses...Then > it must do a 1 in 4billion guess for the Vtag... > > On the other hand sending an abort with an error cause > sends the same information.. in fact probably it points > out which addresses are valid :-0 > > So I wonder if <2> is not best, leave the optional error clause but > warn that using it may reveal information to potential attackers.. or > maybe just kill the cause... not sure... But... When sending an INIT, how could you get an ABORT back (without error causes)? We have the next possible error causes as an answer to the INIT: - Missing Mandatory Parameter - Out of Resource - Unresolvable Address - Invalid Mandatory Parameter - Unrecognized Parameters I don't know now about any situation in which you would send an empty ABORT as a response to an INIT. So most probably receiving a plain ABORT simply means 'Restart of an association with new addresses'... :-/ We could also use the 'User Initiated Abort'... And to get to this situation the attacker must have guessed already the address and port of the sender... which might not be really such a hard task either... :-0 In any case if the attacker ends up NOT having a COOKIE ACK back, it also means that there is something going wrong. If it not an 'Out of Resource' problem, neither a 'Cookie Received While Shutting Down', because otherwise the ABORT would have carried that error case. Again, you can use the 'User Initiated Abort' to leave things a little bit more 'mysterious'... I think that in the best case, hiding the real error cause to confuse the attacker, could at most mean 5-6 reasons (and one of those is in reality an implicit 'Restart of an association with new addresses')... What's that, 3 extra bits of security? :-) > This is definetly a question for Steve... Yes. I won't be at the IETF this time, so keep me informed! BR Iván Arias Rodríguez > R > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > > > > > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > From owner-extdom.sctp-impl@sj-core-5.cisco.com Wed Mar 12 11:36:40 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10394 for ; Wed, 12 Mar 2003 11:36:38 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2CGYHhs028867; Wed, 12 Mar 2003 08:34:17 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEL16229; Wed, 12 Mar 2003 08:34:16 -0800 (PST) Message-ID: <3E6F6187.8070801@cisco.com> Date: Wed, 12 Mar 2003 10:34:15 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: bidulock@openss7.org, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez@nokia.com wrote: >>> Do you mean that the IG doesn't say that you have to >>> >>> >>send back an ABORT if you are in the ESTABLISHED state? >> >> >>> It does... That's section 5.2.2 :-) >>> >>> The difference is that in the ESTABLISHED state you >>> >>> >>create a new IT, while in the COOKIE ECHO you use the previous one. >> >> >>> BR Iván Arias Rodríguez >>> >>> >>> >>> >>> >>Ahh..more coffee and I have found it :> >> >>So then the only real issue is do we: >> >>1) send ABORT()-> with error cause >>2) send ABORT()-> with no error cause >>3) send INIT-ACK to a known address >> >>or ??? >> >>I can see that <3> does reveal (indirectly) information >>to the attacker... since if you don't respond, and he/she >>does it enough, it can be assured that you do have a >>association up with some of the guessed addresses...Then >>it must do a 1 in 4billion guess for the Vtag... >> >>On the other hand sending an abort with an error cause >>sends the same information.. in fact probably it points >>out which addresses are valid :-0 >> >>So I wonder if <2> is not best, leave the optional error clause but >>warn that using it may reveal information to potential attackers.. or >>maybe just kill the cause... not sure... >> >> > > But... When sending an INIT, how could you get an ABORT back (without error causes)? We have the next possible error causes as an answer to the INIT: > > - Missing Mandatory Parameter > - Out of Resource > - Unresolvable Address > - Invalid Mandatory Parameter > - Unrecognized Parameters > > I don't know now about any situation in which you would send an empty ABORT as a response to an INIT. So most probably receiving a plain ABORT simply means 'Restart of an association with new addresses'... :-/ > What about when there is no one listening on that port? I suppose one could send a "out of resource" in this case.. but I think I send just a plain ole ABORT no error cause when this occurs :-0 > > We could also use the 'User Initiated Abort'... > > And to get to this situation the attacker must have guessed already the address and port of the sender... which might not be really such a hard task either... :-0 > > In any case if the attacker ends up NOT having a COOKIE ACK back, it also means that there is something going wrong. If it not an 'Out of Resource' problem, neither a 'Cookie Received While Shutting Down', because otherwise the ABORT would have carried that error case. Again, you can use the 'User Initiated Abort' to leave things a little bit more 'mysterious'... > > I think that in the best case, hiding the real error cause to confuse the attacker, could at most mean 5-6 reasons (and one of those is in reality an implicit 'Restart of an association with new addresses')... What's that, 3 extra bits of security? :-) > I have this on my list of discussions with Steve :> R > > > >>This is definetly a question for Steve... >> >> > > Yes. I won't be at the IETF this time, so keep me informed! > > BR Iván Arias Rodríguez > > > >>R >> >> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> >> >> >> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> >> > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Wed Mar 12 12:30:38 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12417 for ; Wed, 12 Mar 2003 12:30:37 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2CHPWhs025795; Wed, 12 Mar 2003 09:25:32 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEL23267; Wed, 12 Mar 2003 09:25:30 -0800 (PST) Message-ID: <3E6F6D8A.90603@cisco.com> Date: Wed, 12 Mar 2003 11:25:30 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: bidulock@openss7.org, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez@nokia.com wrote: > ... snip... > > > >>> But... When sending an INIT, how could you get an ABORT >>> >>> >>back (without error causes)? We have the next possible error >>causes as an answer to the INIT: >> >> >>> - Missing Mandatory Parameter >>> - Out of Resource >>> - Unresolvable Address >>> - Invalid Mandatory Parameter >>> - Unrecognized Parameters >>> >>> I don't know now about any situation in which you would >>> >>> >>send an empty ABORT as a response to an INIT. So most >>probably receiving a plain ABORT simply means 'Restart of an >>association with new addresses'... :-/ >> >> >>What about when there is no one listening on that port? I suppose one >>could send a "out of resource" in this case.. but I think I >>send just a >>plain ole ABORT no error cause when this occurs :-0 >> >> > > I might be talking nonsense, but, if you are not listening to that port, wouldn't you receive an ICMP 'port unreachable' message? > > BR Iván Arias Rodríguez > > > Well, no not really, you would get a ICMP if there was no protocol registered to handle SCTP.. But just like when you send a SYN to a TCP port that is not listening you get a RST in SCTP you should get an ABORT() I just double verifyed that my new code to handle adding new addresses in a INIT scenario (which used to silently discrd the packet.. opps.. is now going to send the same type of ABORT as a no listner port :>... no error cause at all). R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Wed Mar 12 12:44:21 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13054 for ; Wed, 12 Mar 2003 12:44:20 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CHXs0E018595 for ; Wed, 12 Mar 2003 09:33:54 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2CHX9Hn004205 for ; Wed, 12 Mar 2003 09:33:09 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h2CHUjZi026823 for ; Wed, 12 Mar 2003 09:30:51 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CH2RF13383 for ; Wed, 12 Mar 2003 19:02:27 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 18:58:59 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 18:58:58 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 18:58:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Matching addresses in INIT and INIT ACK Date: Wed, 12 Mar 2003 18:58:57 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLotUFlZVZEBA69ThCdNF+wNBefAwAAyh6Q From: To: Cc: , , X-OriginalArrivalTime: 12 Mar 2003 16:58:57.0653 (UTC) FILETIME=[ABF74250:01C2E8B8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA13054 ... snip... > > But... When sending an INIT, how could you get an ABORT > back (without error causes)? We have the next possible error > causes as an answer to the INIT: > > > > - Missing Mandatory Parameter > > - Out of Resource > > - Unresolvable Address > > - Invalid Mandatory Parameter > > - Unrecognized Parameters > > > > I don't know now about any situation in which you would > send an empty ABORT as a response to an INIT. So most > probably receiving a plain ABORT simply means 'Restart of an > association with new addresses'... :-/ > > > > What about when there is no one listening on that port? I suppose one > could send a "out of resource" in this case.. but I think I > send just a > plain ole ABORT no error cause when this occurs :-0 I might be talking nonsense, but, if you are not listening to that port, wouldn't you receive an ICMP 'port unreachable' message? BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-core-1.cisco.com Wed Mar 12 18:51:26 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00468 for ; Wed, 12 Mar 2003 18:51:25 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CNlr0E027522 for ; Wed, 12 Mar 2003 15:47:53 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2CNlqBv023101 for ; Wed, 12 Mar 2003 15:47:52 -0800 (PST) Received: from gw.openss7.com (IDENT:hRGEWewlxB9onGkyE61gGYpi6GdzzB6F@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h2CNidZi013177 for ; Wed, 12 Mar 2003 15:44:49 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:h3Mc2UQN18ZrZJ1aH8eY/oSrVoxtVefv@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2CNbcD05593; Wed, 12 Mar 2003 16:37:38 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2CNbbB26975; Wed, 12 Mar 2003 16:37:37 -0700 Date: Wed, 12 Mar 2003 16:37:37 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030312163737.B25599@openss7.org> Reply-To: bidulock@openss7.org References: <3E6F3C31.2030203@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E6F3C31.2030203@cisco.com>; from rrs@cisco.com on Wed, Mar 12, 2003 at 07:54:57AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Wed, 12 Mar 2003, Randall Stewart (cisco) wrote: -X- snip -X- > > And thinking about not looking at the addresses (as is currently > done in openss7's stack) you have a very bad situation. The RFC > requires you to silently discard packets with the wrong vtag.. and > NOT respond with an ABORT(). Without checking addresses this > is not possible.. > > You hash to V-Tag/local-port... and you will always return NULL > since you would not find an association that has the wrong V-Tag > ... you get a null in this case when you lookup the association. > Which means you send an ABORT() back to the guy.. > > So If I wish to attack such a stack what I do is start sending HB's (a > rather innocent thing that could be from a previous assoc).... > > Attacker: > Endpoint-A > Src-Does_not_matter:V-Tag-guess-1:HB-----------------------------------> > > Lookup-Vtag() fails (we don't chk the > > address, and vtag is not > matched). > > <---------------ABORT(No-TCB)----------------- > Eventually you get > Src-Does_not_matter:Luckey-guess:HB------------------------------------> > > Lookup-Vtag() find assoc > > <----------------HB-ACK--------------------------- > Got Vtag. > > Now if Endpoint-A responds only to known addresses aka sends the HB back to > its peers real address... no big deal.. do this enough and you now have > an assurance > that you have guessed a V-tag that someone is using.. > > Now the attacker can inject any data it wants into the associations tag that > was guessed.. :-0 Good point. I will fix this. If the hash comes back NULL, I will do a sctp_lookup_tcb() which looks up on address pair and port pair and only send an ABORT if that lookup fails. The fix would apply to all such chunks: (SHUTDOWN, SACK, HEARTBEAT, HEARTBEAT-ACK and DATA). This change in sctp_recv_ootb() will do the trick. Index: sctp.c =================================================================== RCS file: /home/common/cvsroot/linux/net/ipv4/sctp.c,v retrieving revision 1.9.2.36 diff -r1.9.2.36 sctp.c 11478c11478,11481 < sctp_send_abort_ootb(iph->saddr, iph->daddr, sh); --- > #ifndef CONFIG_SCTP_SLOW_VERIFICATION > if (!sctp_lookup_tcb(sh->srce, sh->dest, iph->saddr, iph->daddr)) > #endif > sctp_send_abort_ootb(iph->saddr, iph->daddr, sh); The lookup is also then performed only if some such packet is actually sent, and we have not already checked addresses in sctp_lookup_vtag because CONFIG_SCTP_SLOW_VERIFICATION is not set. Thanks for the security fix. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 13 08:26:23 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29762 for ; Thu, 13 Mar 2003 08:26:21 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2DDMo0E012493; Thu, 13 Mar 2003 05:22:50 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEM46819; Thu, 13 Mar 2003 05:22:49 -0800 (PST) Message-ID: <3E708628.4070005@cisco.com> Date: Thu, 13 Mar 2003 07:22:48 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <3E6F3C31.2030203@cisco.com> <20030312163737.B25599@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian: Glad I could help.. As long as you are at it you might also want to look at: 1) Getting the V-tag security back up to what it should be aka a 1 in 4billion guess 2) You might also want to take a look at fixing this security bug the rest of the way as well, since you have not quite covered all cases and an attack still exists. 3) You might also want to conform to the RFC on recieving a INIT while in COOKIE-WAIT.. unless you pre-know all the addresses you will not respond properly.. unless of course this is a requirement of your stack... I have never yet understood which it is aka... a) required to know all addresses a-priori or b) you don't have to know all of your peers addresses.... if a) then you don' need to worry about 3) But in any case fixing 1 and 2 would definetly increase security... R Brian F. G. Bidulock wrote: >Randall, > >On Wed, 12 Mar 2003, Randall Stewart (cisco) wrote: > >-X- snip -X- > > >>And thinking about not looking at the addresses (as is currently >>done in openss7's stack) you have a very bad situation. The RFC >>requires you to silently discard packets with the wrong vtag.. and >>NOT respond with an ABORT(). Without checking addresses this >>is not possible.. >> >>You hash to V-Tag/local-port... and you will always return NULL >>since you would not find an association that has the wrong V-Tag >>... you get a null in this case when you lookup the association. >>Which means you send an ABORT() back to the guy.. >> >>So If I wish to attack such a stack what I do is start sending HB's (a >>rather innocent thing that could be from a previous assoc).... >> >>Attacker: >> Endpoint-A >>Src-Does_not_matter:V-Tag-guess-1:HB-----------------------------------> >> >> Lookup-Vtag() fails (we don't chk the >> >> address, and vtag is not >>matched). >> >> <---------------ABORT(No-TCB)----------------- >>Eventually you get >>Src-Does_not_matter:Luckey-guess:HB------------------------------------> >> >> Lookup-Vtag() find assoc >> >><----------------HB-ACK--------------------------- >>Got Vtag. >> >>Now if Endpoint-A responds only to known addresses aka sends the HB back to >>its peers real address... no big deal.. do this enough and you now have >>an assurance >>that you have guessed a V-tag that someone is using.. >> >>Now the attacker can inject any data it wants into the associations tag that >>was guessed.. :-0 >> >> > >Good point. I will fix this. If the hash comes back NULL, I will do a >sctp_lookup_tcb() which looks up on address pair and port pair and only >send an ABORT if that lookup fails. The fix would apply to all such chunks: >(SHUTDOWN, SACK, HEARTBEAT, HEARTBEAT-ACK and DATA). This change in >sctp_recv_ootb() will do the trick. > > Index: sctp.c > =================================================================== > RCS file: /home/common/cvsroot/linux/net/ipv4/sctp.c,v > retrieving revision 1.9.2.36 > diff -r1.9.2.36 sctp.c > 11478c11478,11481 > < sctp_send_abort_ootb(iph->saddr, iph->daddr, sh); > --- > > #ifndef CONFIG_SCTP_SLOW_VERIFICATION > > if (!sctp_lookup_tcb(sh->srce, sh->dest, iph->saddr, iph->daddr)) > > #endif > > sctp_send_abort_ootb(iph->saddr, iph->daddr, sh); > >The lookup is also then performed only if some such packet is actually sent, >and we have not already checked addresses in sctp_lookup_vtag because >CONFIG_SCTP_SLOW_VERIFICATION is not set. > >Thanks for the security fix. > >--brian > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 13 15:23:07 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17592 for ; Thu, 13 Mar 2003 15:23:06 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2DKJU0E006730 for ; Thu, 13 Mar 2003 12:19:30 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2DKJTUk012765 for ; Thu, 13 Mar 2003 12:19:29 -0800 (PST) Received: from gw.openss7.com (IDENT:P/kTzU4mxRoTbfr5wSZvrHzgkzKPYkTo@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2DKJaYX014222 for ; Thu, 13 Mar 2003 12:19:41 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:RcFRzhcBasFeMyGsvlWEQY+eN+5tT667@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2DKC4D27016; Thu, 13 Mar 2003 13:12:05 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2DKC4K17004; Thu, 13 Mar 2003 13:12:04 -0700 Date: Thu, 13 Mar 2003 13:12:04 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030313131204.A16701@openss7.org> Reply-To: bidulock@openss7.org References: <3E6F3C31.2030203@cisco.com> <20030312163737.B25599@openss7.org> <3E708628.4070005@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E708628.4070005@cisco.com>; from rrs@cisco.com on Thu, Mar 13, 2003 at 07:22:48AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Thu, 13 Mar 2003, Randall Stewart (cisco) wrote: > > Brian: > > Glad I could help.. > > As long as you are at it you might also want to look at: > > 1) Getting the V-tag security back up to what it should be aka a 1 in > 4billion guess Set CONFIG_SCTP_SLOW_VERIFICATION. > 2) You might also want to take a look at fixing this security bug the > rest of the way as well, since you have not quite covered all cases > and an > attack still exists. Could you please point out where the attack still exists? --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 13 17:03:48 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21219 for ; Thu, 13 Mar 2003 17:03:47 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2DM0v0G018415; Thu, 13 Mar 2003 14:00:59 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEN13850; Thu, 13 Mar 2003 14:00:56 -0800 (PST) Message-ID: <3E70FF98.4050405@cisco.com> Date: Thu, 13 Mar 2003 16:00:56 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <3E6F3C31.2030203@cisco.com> <20030312163737.B25599@openss7.org> <3E708628.4070005@cisco.com> <20030313131204.A16701@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Thu, 13 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian: >> >>Glad I could help.. >> >>As long as you are at it you might also want to look at: >> >>1) Getting the V-tag security back up to what it should be aka a 1 in >>4billion guess >> >> > >Set CONFIG_SCTP_SLOW_VERIFICATION. > > > >>2) You might also want to take a look at fixing this security bug the >> rest of the way as well, since you have not quite covered all cases >>and an >> attack still exists. >> >> > >Could you please point out where the attack still exists? > >--brian > > > You should be able to easily spot it.. but even besides that.. I don't think your fix really works... Now instead of doing: ----------src-does-not-matter:VT:guess-1:HB---------> <---------------ABORT(no-tcb)--------------------------- until I get a HB-ACK I instead do ------src-does-not-matter:VT:guess-1:HB-----------> .. -----src-does-not-matter:VT:guess-2:HB-------------> until <--------------HB-ACK() and assuming the guy is close, say 10ms, you could guess 100 vtags a second... so depending on the number of associations you have up.. it should not take much more than an hour or two to get a hit... as you said, script kiddy's will love this :> The key issue is you have to verify the source addresse as well.. otherwise you have enabled a easy probing of your implementation for V=Tags.. Besides of course the other one... which is a similar reverse attack. Now if you only have one association up it might not be a big concern... since then you only have a 1 in 4billion chance of getting in.. But a stack that checks the src address does not have this worry.. since if the attacker were to somehow guess and spoof the src address on the HB or any chunk that requires a response for that matter and get the Vtag guessed as well.. the response does not go back to him... as it does with implementations that do not check the src address at all... The proper response to HB DATA HB-ACK SACK SHUTDOWN INIT (with no listner) COOKIE-ECHO(with no listner) ERRORS (that are NOT a stale cookie error) is always an ABORT... and the key here is that the src address MUST be right or else the attack is enabled... R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Thu Mar 13 19:06:35 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26217 for ; Thu, 13 Mar 2003 19:06:34 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2E035hs025032 for ; Thu, 13 Mar 2003 16:03:05 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2E034pE029996 for ; Thu, 13 Mar 2003 16:03:04 -0800 (PST) Received: from gw.openss7.com (IDENT:NJD3WIA+p842w83YeWNeJoZzMX8dtwcB@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2E03FYX012444 for ; Thu, 13 Mar 2003 16:03:19 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:PG+gWfMrD3wkI2CXVafVsfi5npBoRO0H@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2DNtgD30868; Thu, 13 Mar 2003 16:55:42 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2DNtg222874; Thu, 13 Mar 2003 16:55:42 -0700 Date: Thu, 13 Mar 2003 16:55:41 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030313165541.A22724@openss7.org> Reply-To: bidulock@openss7.org References: <3E6F3C31.2030203@cisco.com> <20030312163737.B25599@openss7.org> <3E708628.4070005@cisco.com> <20030313131204.A16701@openss7.org> <3E70FF98.4050405@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E70FF98.4050405@cisco.com>; from rrs@cisco.com on Thu, Mar 13, 2003 at 04:00:56PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Thu, 13 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >Randall, > > > >On Thu, 13 Mar 2003, Randall Stewart (cisco) wrote: > > > > > > > >>Brian: > >> > >>Glad I could help.. > >> > >>As long as you are at it you might also want to look at: > >> > >>1) Getting the V-tag security back up to what it should be aka a 1 in > >>4billion guess > >> > >> > > > >Set CONFIG_SCTP_SLOW_VERIFICATION. > > > > > > > >>2) You might also want to take a look at fixing this security bug the > >> rest of the way as well, since you have not quite covered all cases > >>and an > >> attack still exists. > >> > >> > > > >Could you please point out where the attack still exists? > > > >--brian > > > > > > > You should be able to easily spot it.. but even besides that.. I don't think > your fix really works... > > Now instead of doing: > > > ----------src-does-not-matter:VT:guess-1:HB---------> > <---------------ABORT(no-tcb)--------------------------- > > until I get a HB-ACK > > I instead do > > ------src-does-not-matter:VT:guess-1:HB-----------> > .. > -----src-does-not-matter:VT:guess-2:HB-------------> > > until > > <--------------HB-ACK() The implementation will only ever HEARTBEAT-ACK to an address that is part of the existing association, so the attacker will never see it. So the attacker gets nothing back in any case and cannot use this approach to determine VT. Could you please point out the other case? --brian > > and assuming the guy is close, say 10ms, you could guess > 100 vtags a second... so depending on the number of associations > you have up.. it should not take much more than an hour or two > to get a hit... as you said, script kiddy's will love this :> > > The key issue is you have to verify the source addresse as > well.. otherwise you have enabled a easy probing of your implementation > for V=Tags.. Besides of course the other one... which is a similar reverse > attack. Now if you only have one association up it might not be a big > concern... since then you only have a 1 in 4billion chance of getting in.. > > But a stack that checks the src address does not have this worry.. since > if the attacker were to somehow guess and spoof the src address on the > HB or any chunk that requires a response for that matter and get the > Vtag guessed as well.. the response does not go back to him... > as it does with implementations that do not check the src address at all... > > > The proper response to > > HB > DATA > HB-ACK > SACK > SHUTDOWN > INIT (with no listner) > COOKIE-ECHO(with no listner) > ERRORS (that are NOT a stale cookie error) > > is always an ABORT... and the key here is that the src address > MUST be right or else the attack is enabled... > > > > R > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 13 19:19:07 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26444 for ; Thu, 13 Mar 2003 19:19:05 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2E0GC0E027816; Thu, 13 Mar 2003 16:16:13 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEN34448; Thu, 13 Mar 2003 16:16:11 -0800 (PST) Message-ID: <3E711F4B.6070403@cisco.com> Date: Thu, 13 Mar 2003 18:16:11 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <3E6F3C31.2030203@cisco.com> <20030312163737.B25599@openss7.org> <3E708628.4070005@cisco.com> <20030313131204.A16701@openss7.org> <3E70FF98.4050405@cisco.com> <20030313165541.A22724@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Thu, 13 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian F. G. Bidulock wrote: >> >> >> >>>Randall, >>> >>>On Thu, 13 Mar 2003, Randall Stewart (cisco) wrote: >>> >>> >>> >>> >>> >>>>Brian: >>>> >>>>Glad I could help.. >>>> >>>>As long as you are at it you might also want to look at: >>>> >>>>1) Getting the V-tag security back up to what it should be aka a 1 in >>>>4billion guess >>>> >>>> >>>> >>>> >>>Set CONFIG_SCTP_SLOW_VERIFICATION. >>> >>> >>> >>> >>> >>>>2) You might also want to take a look at fixing this security bug the >>>> rest of the way as well, since you have not quite covered all cases >>>>and an >>>> attack still exists. >>>> >>>> >>>> >>>> >>>Could you please point out where the attack still exists? >>> >>>--brian >>> >>> >>> >>> >>> >>You should be able to easily spot it.. but even besides that.. I don't think >>your fix really works... >> >>Now instead of doing: >> >> >>----------src-does-not-matter:VT:guess-1:HB---------> >><---------------ABORT(no-tcb)--------------------------- >> >>until I get a HB-ACK >> >>I instead do >> >>------src-does-not-matter:VT:guess-1:HB-----------> >>.. >>-----src-does-not-matter:VT:guess-2:HB-------------> >> >>until >> >><--------------HB-ACK() >> >> > >The implementation will only ever HEARTBEAT-ACK to an address >that is part of the existing association, so the attacker will >never see it. So the attacker gets nothing back in any case >and cannot use this approach to determine VT. > >Could you please point out the other case? > Really: STATIC int sctp_recv_heartbeat(sp, mp) sctp_t *sp; mblk_t *mp; { struct sctp_heartbeat *m; struct sctpphdr *ph; size_t plen; assert( sp ); assert( mp ); m = (struct sctp_heartbeat *)mp->b_rptr; ph = (struct sctpphdr *)(m+1); plen = PADC(htons(m->ch.len)) - sizeof(*m); if ( plen >= sizeof(struct sctpphdr) ) { if ( ph->type == SCTP_PTYPE_HEARTBEAT_INFO ) { { caddr_t hptr = (caddr_t)ph; size_t hlen = min(plen, PADC(ntohs(ph->len))); sctp_send_heartbeat_ack(sp, hptr, hlen); return sctp_return_stop(mp); } AND int sctp_recv_msg(sp, mp) sctp_t *sp; mblk_t *mp; { int err = -EMSGSIZE; if ( mp ) { /* set the address for reply chunks */ if ( sp->daddr ) { sp->caddr = sctp_find_daddr(sp, ((struct iphdr *)mp->b_datap->db_base)->saddr); normal( sp->caddr ); } do { int dlen = mp->b_wptr - mp->b_rptr; struct sctpchdr *ch = (struct sctpchdr *)mp->b_rptr; unusual( dlen < 0 ); if ( dlen > 0 && dlen >= sizeof(*ch) && dlen >= PADC(ntohs(ch->len)) ) { switch ( (ch->type & SCTP_CTYPE_MASK) ) { case SCTP_CTYPE_DATA: err = sctp_recv_data (sp, mp); break; case SCTP_CTYPE_INIT: err = sctp_recv_init (sp, mp); break; case SCTP_CTYPE_INIT_ACK: err = sctp_recv_init_ack (sp, mp); break; case SCTP_CTYPE_SACK: err = sctp_recv_sack (sp, mp); break; case SCTP_CTYPE_HEARTBEAT: err = sctp_recv_heartbeat (sp, mp); break; I don't see anything that stops the heartbeat from being sent... Of course, as I said, there is another obvious attack as well... R > >--brian > > > > >>and assuming the guy is close, say 10ms, you could guess >>100 vtags a second... so depending on the number of associations >>you have up.. it should not take much more than an hour or two >>to get a hit... as you said, script kiddy's will love this :> >> >>The key issue is you have to verify the source addresse as >>well.. otherwise you have enabled a easy probing of your implementation >>for V=Tags.. Besides of course the other one... which is a similar reverse >>attack. Now if you only have one association up it might not be a big >>concern... since then you only have a 1 in 4billion chance of getting in.. >> >>But a stack that checks the src address does not have this worry.. since >>if the attacker were to somehow guess and spoof the src address on the >>HB or any chunk that requires a response for that matter and get the >>Vtag guessed as well.. the response does not go back to him... >>as it does with implementations that do not check the src address at all... >> >> >>The proper response to >> >>HB >>DATA >>HB-ACK >>SACK >>SHUTDOWN >>INIT (with no listner) >>COOKIE-ECHO(with no listner) >>ERRORS (that are NOT a stale cookie error) >> >>is always an ABORT... and the key here is that the src address >>MUST be right or else the attack is enabled... >> >> >> >>R >> >> >> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Thu Mar 13 19:45:08 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27343 for ; Thu, 13 Mar 2003 19:45:07 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2E0hMhs029581 for ; Thu, 13 Mar 2003 16:43:23 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2E0hMm8016993 for ; Thu, 13 Mar 2003 16:43:22 -0800 (PST) Received: from gw.openss7.com (IDENT:3941kGTCF9NZPRl+GI4hUgvBJQfEP+t9@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2E0hEAq019079 for ; Thu, 13 Mar 2003 16:43:15 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:MfRRPujWMjWUeBt4TmG/nGwB1HihuzBU@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2E0b6D31732; Thu, 13 Mar 2003 17:37:06 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2E0b6O23783; Thu, 13 Mar 2003 17:37:06 -0700 Date: Thu, 13 Mar 2003 17:37:06 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030313173706.A23572@openss7.org> Reply-To: bidulock@openss7.org References: <3E6F3C31.2030203@cisco.com> <20030312163737.B25599@openss7.org> <3E708628.4070005@cisco.com> <20030313131204.A16701@openss7.org> <3E70FF98.4050405@cisco.com> <20030313165541.A22724@openss7.org> <3E711F4B.6070403@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E711F4B.6070403@cisco.com>; from rrs@cisco.com on Thu, Mar 13, 2003 at 06:16:11PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Thu, 13 Mar 2003, Randall Stewart (cisco) wrote: > >> > >>until > >> > >><--------------HB-ACK() > >> > >> > > > >The implementation will only ever HEARTBEAT-ACK to an address > >that is part of the existing association, so the attacker will > >never see it. So the attacker gets nothing back in any case > >and cannot use this approach to determine VT. > > > >Could you please point out the other case? > > > > > Really: Yes really: STATIC void sctp_send_heartbeat_ack(sp, hptr, hlen) sctp_t *sp; caddr_t hptr; size_t hlen; { sctp_daddr_t *sd; assert(sp); ====> if ((sd = sctp_route_response(sp))) { mblk_t *mp; struct sctp_heartbeat_ack *m; size_t clen = sizeof(*m) + hlen; size_t plen = PADC(clen); if ((mp = sctp_alloc_msg(sp, clen))) { m = (struct sctp_heartbeat_ack *) mp->b_wptr; m->ch.type = SCTP_CTYPE_HEARTBEAT_ACK; m->ch.flags = 0; m->ch.len = htons(clen); bcopy(hptr, (m + 1), hlen); mp->b_wptr += plen; sctp_send_msg(sp, sd, mp); freechunks(mp); } } } STATIC sctp_daddr_t *sctp_route_response(sp) sctp_t *sp; { sctp_daddr_t *sd; assert(sp); ====> sd = sp->caddr; ====> if (!sd || !sd->dst_cache || sd->retransmits) sd = sctp_route_normal(sp); normal(sd); return (sd); } int sctp_recv_msg(sp, mp) sctp_t *sp; mblk_t *mp; { int err = -EMSGSIZE; if (mp) { /* set the address for reply chunks */ if (sp->daddr) { ====> sp->caddr = sctp_find_daddr(sp, ((struct iphdr *) mp->b_datap->db_base)->saddr); normal(sp->caddr); } . . . . The HEARTBEAT-ACK will never be sent to an address other than a valid destination address for the association. The attacker will not receive the HEARTBEAT-ACK. -X- snip -X- > > I don't see anything that stops the heartbeat from being sent... Well, first it is the HEARTBEAT-ACK that you say is being sent to the attacker in your example. It is being sent, but will not be sent to the attacker, so the attacker always gets nothing and can not determine the VT this way. > > Of course, as I said, there is another obvious attack as well... Please describe this other obvious attack. I am interested to see it. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-5.cisco.com Fri Mar 14 07:14:28 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23569 for ; Fri, 14 Mar 2003 07:14:26 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2EC4Nhs023794; Fri, 14 Mar 2003 04:04:24 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEN80404; Fri, 14 Mar 2003 04:04:22 -0800 (PST) Message-ID: <3E71C545.2010003@cisco.com> Date: Fri, 14 Mar 2003 06:04:21 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <3E6F3C31.2030203@cisco.com> <20030312163737.B25599@openss7.org> <3E708628.4070005@cisco.com> <20030313131204.A16701@openss7.org> <3E70FF98.4050405@cisco.com> <20030313165541.A22724@openss7.org> <3E711F4B.6070403@cisco.com> <20030313173706.A23572@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: > > >Please describe this other obvious attack. I am interested to see it. > > > Think about SHUTDOWN-ACK's. Oh, one other little salient point.. The whole purpose of always getting an ABORT back to HB's is to clean up state. So one other little issue with your fix... consider this: Host A Host B --------- ------------ Host A initiates---> <--------------Valid association-----------------------------> (Restart of Host-B) --------------------HB----------------------------> Now the normal and RFC compliant response is to send <-------------------ABORT(no-tcb)---------------------------- So that Host A can clean up its state and restart the association (if the app so chooses).. But with your little fix you would deem Host-A an attacker and ignore the HB's... Bottom line is you should always send an ABORT back to the chunk types I put in one of my previous emails when you either don't have a listner or no-tcb... R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-2.cisco.com Fri Mar 14 12:53:28 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04006 for ; Fri, 14 Mar 2003 12:53:27 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2EHooEY019173 for ; Fri, 14 Mar 2003 09:50:50 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2EHohVP026557 for ; Fri, 14 Mar 2003 09:50:48 -0800 (PST) Received: from gw.openss7.com (IDENT:gbLatALmyh9SU8EL1YK2DmADivK0TsTX@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2EHoSvS015318 for ; Fri, 14 Mar 2003 09:50:39 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:ZWtJod/F4rZRWrmVG4kJNFjccRcMr4nu@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2EHhjD16799; Fri, 14 Mar 2003 10:43:45 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2EHhiq08765; Fri, 14 Mar 2003 10:43:44 -0700 Date: Fri, 14 Mar 2003 10:43:44 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030314104344.A8236@openss7.org> Reply-To: bidulock@openss7.org References: <3E6F3C31.2030203@cisco.com> <20030312163737.B25599@openss7.org> <3E708628.4070005@cisco.com> <20030313131204.A16701@openss7.org> <3E70FF98.4050405@cisco.com> <20030313165541.A22724@openss7.org> <3E711F4B.6070403@cisco.com> <20030313173706.A23572@openss7.org> <3E71C545.2010003@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E71C545.2010003@cisco.com>; from rrs@cisco.com on Fri, Mar 14, 2003 at 06:04:21AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Fri, 14 Mar 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > > > > > >Please describe this other obvious attack. I am interested to see it. > > > > > > > Think about SHUTDOWN-ACK's. Yes, that was so obvious, it was already fixed: STATIC int sctp_rcv_ootb(struct sk_buff * skb) { struct iphdr *iph = skb->nh.iph; struct sctphdr *sh = skb->h.sh; struct sctpchdr *ch = (typeof(ch)) skb->data; int sat = inet_addr_type(iph->saddr); seldom(); ensure(skb, return (-EFAULT)); if (sat != RTN_UNICAST && sat != RTN_LOCAL) { /* RFC 2960 8.4(1) */ kfree_skb(skb); return (0); } switch (ch->type) { case SCTP_CTYPE_COOKIE_ACK: /* RFC 2960 8.4(7). */ case SCTP_CTYPE_ERROR: /* RFC 2960 8.4(7). */ case SCTP_CTYPE_ABORT: /* RFC 2960 8.4(2). */ case SCTP_CTYPE_SHUTDOWN_COMPLETE: /* RFC 2960 8.4(6). */ case SCTP_CTYPE_INIT: /* RFC 2960 8.4(3) and (8). */ case SCTP_CTYPE_INIT_ACK: /* RFC 2960 8.4(8). */ case SCTP_CTYPE_COOKIE_ECHO: /* RFC 2960 8.4(4) and (8). */ default: seldom(); break; case SCTP_CTYPE_SHUTDOWN: /* RFC 2960 8.4(8). */ case SCTP_CTYPE_SACK: /* RFC 2960 8.4(8). */ case SCTP_CTYPE_HEARTBEAT: /* RFC 2960 8.4(8). */ case SCTP_CTYPE_HEARTBEAT_ACK: /* RFC 2960 8.4(8). */ case SCTP_CTYPE_DATA: /* RFC 2960 8.4(8). */ seldom(); #ifndef CONFIG_SCTP_SLOW_VERIFICATION if (!sctp_lookup_tcb(sh->srce, sh->dest, iph->saddr, iph->daddr)) #endif sctp_send_abort_ootb(iph->saddr, iph->daddr, sh); break; case SCTP_CTYPE_SHUTDOWN_ACK: seldom(); #ifndef CONFIG_SCTP_SLOW_VERIFICATION if (!sctp_lookup_tcb(sh->srce, sh->dest, iph->saddr, iph->daddr)) #endif sctp_send_shutdown_complete_ootb(iph->saddr, iph->daddr, sh); break; } kfree_skb(skb); return (0); } > > Oh, one other little salient point.. The whole purpose of always getting > an ABORT back to HB's is to clean up state. So one other little > issue with your fix... consider this: > > Host A > Host B > --------- > ------------ > Host A initiates---> > <--------------Valid association-----------------------------> > > (Restart of Host-B) > > --------------------HB----------------------------> > > > Now the normal and RFC compliant response is to send > > <-------------------ABORT(no-tcb)---------------------------- > > So that Host A can clean up its state and restart the > association (if the app so chooses).. > > But with your little fix you would deem Host-A an attacker > and ignore the HB's... The fix doesn't deem anybody an attacker. It just searches on port and address pair if a vtag match is not found. If no tcb exists the ABORT is sent. The error was that ABORT was sent when vtag didn't match but a tcb existed if CONFIG_SCTP_SLOW_VERIFICATION was not set. The fix corrects that to only sending ABORT when the vtag doesn't match and a tcb does not exist regardless of the setting of CONFIG_SCTP_SLOW_VERIFICATION. > > Bottom line is you should always send an ABORT back to the > chunk types I put in one of my previous emails when you > either don't have a listner or no-tcb... That's what the fix does. Thanks again for pointing it out. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-5.cisco.com Fri Mar 14 13:23:35 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04782 for ; Fri, 14 Mar 2003 13:23:33 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2EILVhs003132; Fri, 14 Mar 2003 10:21:31 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEO10641; Fri, 14 Mar 2003 10:21:29 -0800 (PST) Message-ID: <3E721DA8.4030409@cisco.com> Date: Fri, 14 Mar 2003 12:21:28 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <3E6F3C31.2030203@cisco.com> <20030312163737.B25599@openss7.org> <3E708628.4070005@cisco.com> <20030313131204.A16701@openss7.org> <3E70FF98.4050405@cisco.com> <20030313165541.A22724@openss7.org> <3E711F4B.6070403@cisco.com> <20030313173706.A23572@openss7.org> <3E71C545.2010003@cisco.com> <20030314104344.A8236@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Fri, 14 Mar 2003, Randall Stewart (cisco) wrote: > > > >>Brian F. G. Bidulock wrote: >> >> >> >>> >>> >>>Please describe this other obvious attack. I am interested to see it. >>> >>> >>> >>> >>> >>Think about SHUTDOWN-ACK's. >> >> > >Yes, that was so obvious, it was already fixed: > > Great, I am glad you found it.. now let me get something straight because I am still confused by your "fixes" ... You reach here (sctp_rcv_ootb()) out of the input due to the fact that the VT did not match... and so you could not find a TCB.. > STATIC int sctp_rcv_ootb(struct sk_buff * skb) > { > struct iphdr *iph = skb->nh.iph; > struct sctphdr *sh = skb->h.sh; > struct sctpchdr *ch = (typeof(ch)) skb->data; > int sat = inet_addr_type(iph->saddr); > seldom(); > ensure(skb, return (-EFAULT)); > if (sat != RTN_UNICAST && sat != RTN_LOCAL) { > /* RFC 2960 8.4(1) */ > kfree_skb(skb); > return (0); > } > switch (ch->type) { > case SCTP_CTYPE_COOKIE_ACK: /* RFC 2960 8.4(7). */ > case SCTP_CTYPE_ERROR: /* RFC 2960 8.4(7). */ > case SCTP_CTYPE_ABORT: /* RFC 2960 8.4(2). */ > case SCTP_CTYPE_SHUTDOWN_COMPLETE: /* RFC 2960 8.4(6). */ > case SCTP_CTYPE_INIT: /* RFC 2960 8.4(3) and (8). */ > case SCTP_CTYPE_INIT_ACK: /* RFC 2960 8.4(8). */ > case SCTP_CTYPE_COOKIE_ECHO: /* RFC 2960 8.4(4) and (8). */ > default: > seldom(); > break; > case SCTP_CTYPE_SHUTDOWN: /* RFC 2960 8.4(8). */ > case SCTP_CTYPE_SACK: /* RFC 2960 8.4(8). */ > case SCTP_CTYPE_HEARTBEAT: /* RFC 2960 8.4(8). */ > case SCTP_CTYPE_HEARTBEAT_ACK: /* RFC 2960 8.4(8). */ > case SCTP_CTYPE_DATA: /* RFC 2960 8.4(8). */ > seldom(); > assuming you hit the IF below... how will you ever match my iph->saddr... an association is up between A---------------------------------------->Z I send a HB(from:X) with Guess-Tag------------>Z Of course Guess-Tag does not match.. so you hit this module.. your hunt for a TCB will return NULL since you don't have an assocation with X right? Which means you send me an Abort... (which is actually correct)... But if I guess the tag correctly.. you don't hit this code.. instead you either send nothing back... or send a HB-ACK (I think you showed in your routing calls that you sent back only to the cached address or some such.. I don't have time to study it..)... But is this not providing me with a guess attack from you? Since if the tag does match I will get nothing back and the peer (A) will get the HB-ACK... Where-as if I do get an abort back if I guess wrong.. The problem is more in the fact that you DO NOT recognize the difference between a Guessed Tag/HB and a HB from the peer by checking the addresses.. a correctly guessed V-Tag with bad source address should also generate a ABORT... > #ifndef CONFIG_SCTP_SLOW_VERIFICATION > if (!sctp_lookup_tcb(sh->srce, sh->dest, iph->saddr, iph->daddr)) > #endif > sctp_send_abort_ootb(iph->saddr, iph->daddr, sh); > break; > case SCTP_CTYPE_SHUTDOWN_ACK: > seldom(); > And here it is the same thing... if I send you my bogus address 'X' you will never find a TCB between X/port <--> Z/port... so you will send me a Shutdown-Complete until I guess the tag.. and then you will silently discard the Shutdown-Ack since you are not in the shutdown state... The source of the problem is not checking the source addresses and handling a non matching source address as an OOTB.. Note also an INIT or COOKIE-ECHO sent to a non-listening port (how you would get here) should also get an ABORT sent back... and same with all but one specific type of ERROR ... R > #ifndef CONFIG_SCTP_SLOW_VERIFICATION > if (!sctp_lookup_tcb(sh->srce, sh->dest, iph->saddr, iph->daddr)) > #endif > sctp_send_shutdown_complete_ootb(iph->saddr, iph->daddr, sh); > break; > } > kfree_skb(skb); > return (0); > } > > > >>Oh, one other little salient point.. The whole purpose of always getting >>an ABORT back to HB's is to clean up state. So one other little >>issue with your fix... consider this: >> >>Host A >> Host B >>--------- >> ------------ >>Host A initiates---> >> <--------------Valid association-----------------------------> >> >> (Restart of Host-B) >> >>--------------------HB----------------------------> >> >> >>Now the normal and RFC compliant response is to send >> >> <-------------------ABORT(no-tcb)---------------------------- >> >>So that Host A can clean up its state and restart the >>association (if the app so chooses).. >> >>But with your little fix you would deem Host-A an attacker >>and ignore the HB's... >> >> > >The fix doesn't deem anybody an attacker. It just searches >on port and address pair if a vtag match is not found. If >no tcb exists the ABORT is sent. > >The error was that ABORT was sent when vtag didn't match but >a tcb existed if CONFIG_SCTP_SLOW_VERIFICATION was not set. >The fix corrects that to only sending ABORT when the vtag >doesn't match and a tcb does not exist regardless of the >setting of CONFIG_SCTP_SLOW_VERIFICATION. > > > >>Bottom line is you should always send an ABORT back to the >>chunk types I put in one of my previous emails when you >>either don't have a listner or no-tcb... >> >> > >That's what the fix does. > >Thanks again for pointing it out. > >--brian > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Sat Mar 15 02:08:39 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06725 for ; Sat, 15 Mar 2003 02:08:37 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2F74Ghs014977 for ; Fri, 14 Mar 2003 23:04:16 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2F74DV4010362 for ; Fri, 14 Mar 2003 23:04:13 -0800 (PST) Received: from gw.openss7.com (IDENT:ygxepBroM93vTMIGZ4PNQXwgWWHYMEpt@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h2F72CrM018300 for ; Fri, 14 Mar 2003 23:02:13 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:yS9NxdlBduXHO/lYQxYp6J5fiaB8Vr2f@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2F6vAD29813; Fri, 14 Mar 2003 23:57:10 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2F6vAP23704; Fri, 14 Mar 2003 23:57:10 -0700 Date: Fri, 14 Mar 2003 23:57:09 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030314235709.A23287@openss7.org> Reply-To: bidulock@openss7.org References: <20030312163737.B25599@openss7.org> <3E708628.4070005@cisco.com> <20030313131204.A16701@openss7.org> <3E70FF98.4050405@cisco.com> <20030313165541.A22724@openss7.org> <3E711F4B.6070403@cisco.com> <20030313173706.A23572@openss7.org> <3E71C545.2010003@cisco.com> <20030314104344.A8236@openss7.org> <3E721DA8.4030409@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E721DA8.4030409@cisco.com>; from rrs@cisco.com on Fri, Mar 14, 2003 at 12:21:28PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Fri, 14 Mar 2003, Randall Stewart (cisco) wrote: -X- snip -X- > > > STATIC int sctp_rcv_ootb(struct sk_buff * skb) > > { > > struct iphdr *iph = skb->nh.iph; > > struct sctphdr *sh = skb->h.sh; > > struct sctpchdr *ch = (typeof(ch)) skb->data; > > int sat = inet_addr_type(iph->saddr); > > seldom(); > > ensure(skb, return (-EFAULT)); > > if (sat != RTN_UNICAST && sat != RTN_LOCAL) { > > /* RFC 2960 8.4(1) */ > > kfree_skb(skb); > > return (0); > > } > > switch (ch->type) { > > case SCTP_CTYPE_COOKIE_ACK: /* RFC 2960 8.4(7). */ > > case SCTP_CTYPE_ERROR: /* RFC 2960 8.4(7). */ > > case SCTP_CTYPE_ABORT: /* RFC 2960 8.4(2). */ > > case SCTP_CTYPE_SHUTDOWN_COMPLETE: /* RFC 2960 8.4(6). */ > > case SCTP_CTYPE_INIT: /* RFC 2960 8.4(3) and (8). */ > > case SCTP_CTYPE_INIT_ACK: /* RFC 2960 8.4(8). */ > > case SCTP_CTYPE_COOKIE_ECHO: /* RFC 2960 8.4(4) and (8). */ > > default: > > seldom(); > > break; > > case SCTP_CTYPE_SHUTDOWN: /* RFC 2960 8.4(8). */ > > case SCTP_CTYPE_SACK: /* RFC 2960 8.4(8). */ > > case SCTP_CTYPE_HEARTBEAT: /* RFC 2960 8.4(8). */ > > case SCTP_CTYPE_HEARTBEAT_ACK: /* RFC 2960 8.4(8). */ > > case SCTP_CTYPE_DATA: /* RFC 2960 8.4(8). */ > > seldom(); > > > > assuming you hit the IF below... how will you ever match my > iph->saddr... > > an association is up between > > A---------------------------------------->Z > > I send a HB(from:X) with Guess-Tag------------>Z > > Of course Guess-Tag does not match.. so you hit this module.. your hunt > for a TCB > will return NULL since you don't have an assocation with X right? Which > means you send me an Abort... (which is actually correct)... Yes. > > But if I guess the tag correctly.. you don't hit this code.. instead you > either send nothing back... or send a HB-ACK (I think you showed in your > routing calls that you sent back only to the cached address or some such.. I > don't have time to study it..)... But is this not providing me with a guess > attack from you? Since if the tag does match I will get nothing back and > the peer (A) will get the HB-ACK... > > Where-as if I do get an abort back if I guess wrong.. > The problem is more in the fact that you DO NOT recognize the difference > between a Guessed Tag/HB and a HB from the peer by checking the > addresses.. a correctly guessed V-Tag with bad source address should > also generate a ABORT... Well no, because of the change from our previous discussions (Mar. 6). The first change was to assure that the verification tag was unique in the hashes. extern uint32_t secure_tcp_sequence_number(uint32_t, uint32_t, uint16_t, uint16_t); STATIC uint32_t sctp_get_vtag(uint32_t daddr, uint32_t saddr, uint16_t dport, uint16_t sport) { uint32_t ret; - ret = secure_tcp_sequence_number(daddr, saddr, dport, sport); - usual(ret); + while (!(ret = secure_tcp_sequence_number(daddr, saddr, dport, sport)) || + sctp_lookup_vtag(ret, sport, dport, saddr, daddr)); return (ret); } This meant that sport was no longer necessary in vtag lookups and vtag could be used alone to find the socket/stream. #if !defined(CONFIG_SCTP_SLOW_VERIFICATION) || defined(CONFIG_SCTP_ADD_IP) #define sctp_match_vtag(__sk, __saddr, __daddr, __v_tag, __sport, __dport) \ - ( ((__v_tag) == SCTP_PROT(__sk)->v_tag) && \ - ((__sport) == (__sk)->sport) ) + ( ((__v_tag) == SCTP_PROT(__sk)->v_tag) ) #else #define sctp_match_vtag(__sk, __saddr, __daddr, __v_tag, __sport, __dport) \ ( ((__v_tag) == SCTP_PROT(__sk)->v_tag) && \ ((__sport) == (__sk)->sport) && \ ((__dport) == (__sk)->dport) && \ - (sctp_find_saddr((__sk),(__daddr))) && \ - (sctp_find_daddr((__sk),(__saddr))) ) + (sctp_find_saddr((__sk),(__daddr))) ) #endif The second change was to test caddr (which is set to the reply address for all packets anyway) in sctp_recv_msg as we discussed. STATIC int sctp_recv_msg(struct sock *sk, struct sk_buff *skb) { int err; struct sctp_opt *sp = SCTP_PROT(sk); struct sctpchdr *ch; ensure(sk, goto efault); ensure(skb, goto efault); /* set address for reply chunks */ - if (sp->daddr) { - sp->caddr = sctp_find_daddr(sk, skb->nh.iph->saddr); - normal(sp->caddr); + if (!(sp->caddr = sctp_find_daddr(sk, skb->nh.iph->saddr))) { + ch = (typeof(ch)) skb->data; + switch (ch->type) { + case SCTP_CTYPE_INIT: + case SCTP_CTYPE_INIT_ACK: + case SCTP_CTYPE_COOKIE_ECHO: + break; + default: + SCTP_INC_STATS_BH(SctpOutOfBlues); + return sctp_rcv_ootb(skb); + } } do { This change meant that source address never needs to be checked when looking up the socket/stream and it was removed from sctp_match_vtag above. One thing about Linux (and STREAMS) is that a backlog is queued against a socket (stream) while the user has the socket/stream locked. Because there might be an INIT-ACK or COOKIE-ECHO in the backlog of messages waiting to be processed, the state of the socket is not current until the backlog is processed. A match against source address would incorrect if an INIT-ACK or COOKIE-ECHO (or ABORT) is in the backlog. This is actually not a rare situation. When the addresses involved are loopback addresses (RTT of about 0) the user often still has the socket locked on connect() when the INIT-ACK is received. Therefore, source addresses cannot be considered until the message is actually processed against the socket/stream that has been found by vtag. Perhaps you can see now why I object to the wording "[w]hen searching for a TCB" in IG 2.18. > > > #ifndef CONFIG_SCTP_SLOW_VERIFICATION > > if (!sctp_lookup_tcb(sh->srce, sh->dest, iph->saddr, iph->daddr)) > > #endif > > sctp_send_abort_ootb(iph->saddr, iph->daddr, sh); > > break; > > case SCTP_CTYPE_SHUTDOWN_ACK: > > seldom(); > > Actually, I removed the ifndef from above as well as the source address is never checked in sctp_lookup_vtag now with the fix to sctp_recv_msg. > > And here it is the same thing... if I send you my bogus address 'X' you > will never > find a TCB between X/port <--> Z/port... so you will send me a > Shutdown-Complete > until I guess the tag.. and then you will silently discard the > Shutdown-Ack since > you are not in the shutdown state... > > The source of the problem is not checking the source addresses and handling > a non matching source address as an OOTB.. Thanks for pointing it out, but I think I've got that one covered. I think the fix I suggested Mar 6 curred that. You didn't see the whole fix (I just showed returning -EPROTO to the caller). See sctp_recv_msg above. Anything matching on vtag that has found a socket/stream which is from a source address not belonging to the socket (except INIT, INIT-ACK and COOKIE-ECHO) will be treated as OOTB there. That fix made SLOW_VERIFICATION the equivalent of RIDICULOUSLY_SLOW_VERIFICATION for vtag lookups. It still has some use for ptag lookups (because the uniqueness of peer tags for a given port pair cannot be completely guaranteed). The change to sctp_get_vtag provides strong assurances that vtags are unique in the vtag hash (well their might be some races, but the randomness of the vtag and the narrow time-window of the race makes it a strong assurance). So, when looking for a TCB all I need to use is vtag. The reason for looking up the source address in sctp_recv_msg was to determine where to send reply chunks. Now the source address is checked for validity just before processing the packet against the TCB solely to thwart the type of attacks you have presented. > > Note also an INIT or COOKIE-ECHO sent to a non-listening port (how you > would get here) should also get an ABORT sent back... and same with all but > one specific type of ERROR ... Well, there are no missing mandatory parameters, no invalid parameter values, and no lack of local resources, so the sender gets static (and an invitation to try again after T1-init). That was intentional. If there are missing mandatory parameters, invalid parameter values or lack of local resources (listen socket backlog exceeded) the ABORT with proper error value is sent in compliance to RFC 2960 Section 5.1. Thanks again for pointing out the ABORT problem. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Sat Mar 15 16:37:14 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26761 for ; Sat, 15 Mar 2003 16:37:12 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2FLXo0E009842; Sat, 15 Mar 2003 13:33:50 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEP12802; Sat, 15 Mar 2003 13:33:48 -0800 (PST) Message-ID: <3E739C3C.6070609@cisco.com> Date: Sat, 15 Mar 2003 15:33:48 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com, cait@asomi.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030312163737.B25599@openss7.org> <3E708628.4070005@cisco.com> <20030313131204.A16701@openss7.org> <3E70FF98.4050405@cisco.com> <20030313165541.A22724@openss7.org> <3E711F4B.6070403@cisco.com> <20030313173706.A23572@openss7.org> <3E71C545.2010003@cisco.com> <20030314104344.A8236@openss7.org> <3E721DA8.4030409@cisco.com> <20030314235709.A23287@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: >Randall, > >On Fri, 14 Mar 2003, Randall Stewart (cisco) wrote: > >-X- snip -X- > > >>> STATIC int sctp_rcv_ootb(struct sk_buff * skb) >>> { >>> struct iphdr *iph = skb->nh.iph; >>> struct sctphdr *sh = skb->h.sh; >>> struct sctpchdr *ch = (typeof(ch)) skb->data; >>> int sat = inet_addr_type(iph->saddr); >>> seldom(); >>> ensure(skb, return (-EFAULT)); >>> if (sat != RTN_UNICAST && sat != RTN_LOCAL) { >>> /* RFC 2960 8.4(1) */ >>> kfree_skb(skb); >>> return (0); >>> } >>> switch (ch->type) { >>> case SCTP_CTYPE_COOKIE_ACK: /* RFC 2960 8.4(7). */ >>> case SCTP_CTYPE_ERROR: /* RFC 2960 8.4(7). */ >>> case SCTP_CTYPE_ABORT: /* RFC 2960 8.4(2). */ >>> case SCTP_CTYPE_SHUTDOWN_COMPLETE: /* RFC 2960 8.4(6). */ >>> case SCTP_CTYPE_INIT: /* RFC 2960 8.4(3) and (8). */ >>> case SCTP_CTYPE_INIT_ACK: /* RFC 2960 8.4(8). */ >>> case SCTP_CTYPE_COOKIE_ECHO: /* RFC 2960 8.4(4) and (8). */ >>> default: >>> seldom(); >>> break; >>> case SCTP_CTYPE_SHUTDOWN: /* RFC 2960 8.4(8). */ >>> case SCTP_CTYPE_SACK: /* RFC 2960 8.4(8). */ >>> case SCTP_CTYPE_HEARTBEAT: /* RFC 2960 8.4(8). */ >>> case SCTP_CTYPE_HEARTBEAT_ACK: /* RFC 2960 8.4(8). */ >>> case SCTP_CTYPE_DATA: /* RFC 2960 8.4(8). */ >>> seldom(); >>> >>> >>> >>assuming you hit the IF below... how will you ever match my >>iph->saddr... >> >>an association is up between >> >>A---------------------------------------->Z >> >>I send a HB(from:X) with Guess-Tag------------>Z >> >>Of course Guess-Tag does not match.. so you hit this module.. your hunt >>for a TCB >>will return NULL since you don't have an assocation with X right? Which >>means you send me an Abort... (which is actually correct)... >> >> > >Yes. > > > >>But if I guess the tag correctly.. you don't hit this code.. instead you >>either send nothing back... or send a HB-ACK (I think you showed in your >>routing calls that you sent back only to the cached address or some such.. I >>don't have time to study it..)... But is this not providing me with a guess >>attack from you? Since if the tag does match I will get nothing back and >>the peer (A) will get the HB-ACK... >> >>Where-as if I do get an abort back if I guess wrong.. >>The problem is more in the fact that you DO NOT recognize the difference >>between a Guessed Tag/HB and a HB from the peer by checking the >>addresses.. a correctly guessed V-Tag with bad source address should >>also generate a ABORT... >> >> > >Well no, because of the change from our previous discussions (Mar. 6). > >The first change was to assure that the verification tag was unique in the >hashes. > > extern uint32_t secure_tcp_sequence_number(uint32_t, uint32_t, uint16_t, uint16_t); > STATIC uint32_t sctp_get_vtag(uint32_t daddr, uint32_t saddr, uint16_t dport, > uint16_t sport) > { > uint32_t ret; > - ret = secure_tcp_sequence_number(daddr, saddr, dport, sport); > - usual(ret); > + while (!(ret = secure_tcp_sequence_number(daddr, saddr, dport, sport)) || > + sctp_lookup_vtag(ret, sport, dport, saddr, daddr)); > return (ret); > } > >This meant that sport was no longer necessary in vtag lookups and vtag could >be used alone to find the socket/stream. > > #if !defined(CONFIG_SCTP_SLOW_VERIFICATION) || defined(CONFIG_SCTP_ADD_IP) > #define sctp_match_vtag(__sk, __saddr, __daddr, __v_tag, __sport, __dport) \ > - ( ((__v_tag) == SCTP_PROT(__sk)->v_tag) && \ > - ((__sport) == (__sk)->sport) ) > + ( ((__v_tag) == SCTP_PROT(__sk)->v_tag) ) > #else > #define sctp_match_vtag(__sk, __saddr, __daddr, __v_tag, __sport, __dport) \ > ( ((__v_tag) == SCTP_PROT(__sk)->v_tag) && \ > ((__sport) == (__sk)->sport) && \ > ((__dport) == (__sk)->dport) && \ > - (sctp_find_saddr((__sk),(__daddr))) && \ > - (sctp_find_daddr((__sk),(__saddr))) ) > + (sctp_find_saddr((__sk),(__daddr))) ) > #endif > >The second change was to test caddr (which is set to the reply address for all >packets anyway) in sctp_recv_msg as we discussed. > > STATIC int sctp_recv_msg(struct sock *sk, struct sk_buff *skb) > { > int err; > struct sctp_opt *sp = SCTP_PROT(sk); > struct sctpchdr *ch; > ensure(sk, goto efault); > ensure(skb, goto efault); > /* set address for reply chunks */ > - if (sp->daddr) { > - sp->caddr = sctp_find_daddr(sk, skb->nh.iph->saddr); > - normal(sp->caddr); > + if (!(sp->caddr = sctp_find_daddr(sk, skb->nh.iph->saddr))) { > + ch = (typeof(ch)) skb->data; > + switch (ch->type) { > + case SCTP_CTYPE_INIT: > + case SCTP_CTYPE_INIT_ACK: > + case SCTP_CTYPE_COOKIE_ECHO: > + break; > + default: > + SCTP_INC_STATS_BH(SctpOutOfBlues); > + return sctp_rcv_ootb(skb); > + } > } > do { > >This change meant that source address never needs to be checked when looking >up the socket/stream and it was removed from sctp_match_vtag above. > > Hmm.. this is better.. it does tighten security a bit more... >One thing about Linux (and STREAMS) is that a backlog is queued against a >socket (stream) while the user has the socket/stream locked. Because there >might be an INIT-ACK or COOKIE-ECHO in the backlog of messages waiting to be >processed, the state of the socket is not current until the backlog is >processed. A match against source address would incorrect if an INIT-ACK or >COOKIE-ECHO (or ABORT) is in the backlog. > >This is actually not a rare situation. When the addresses involved are >loopback addresses (RTT of about 0) the user often still has the socket locked >on connect() when the INIT-ACK is received. > >Therefore, source addresses cannot be considered until the message is actually >processed against the socket/stream that has been found by vtag. > >Perhaps you can see now why I object to the wording "[w]hen searching for a >TCB" in IG 2.18. > > But in any event .. wording in the IG 2.18 or not.. you are still not compliant to the RFC... you are supposed to use the same V-tag when the crossing INIT's occur... I think we will adopt Ivan's suggested wording.. but note that it requires you to have the "same" result as if you had used the addresses... aka so you properly include the same V-Tag when you send a INIT-ACK to someone who is colliding with you... It is an unfortunate that you went with a design that can't meet the requirements.. I hope that LK-SCTP did not do this too.. (I don't think so from my earlier conversations with La Monte... ) that way at least one of the implementations is RFC2960 compliant... > > >>> #ifndef CONFIG_SCTP_SLOW_VERIFICATION >>> if (!sctp_lookup_tcb(sh->srce, sh->dest, iph->saddr, iph->daddr)) >>> #endif >>> sctp_send_abort_ootb(iph->saddr, iph->daddr, sh); >>> break; >>> case SCTP_CTYPE_SHUTDOWN_ACK: >>> seldom(); >>> >>> >>> > >Actually, I removed the ifndef from above as well as the source address >is never checked in sctp_lookup_vtag now with the fix to sctp_recv_msg. > > > >>And here it is the same thing... if I send you my bogus address 'X' you >>will never >>find a TCB between X/port <--> Z/port... so you will send me a >>Shutdown-Complete >>until I guess the tag.. and then you will silently discard the >>Shutdown-Ack since >>you are not in the shutdown state... >> >>The source of the problem is not checking the source addresses and handling >>a non matching source address as an OOTB.. >> >> > >Thanks for pointing it out, but I think I've got that one covered. I think >the fix I suggested Mar 6 curred that. You didn't see the whole fix (I just >showed returning -EPROTO to the caller). See sctp_recv_msg above. Anything >matching on vtag that has found a socket/stream which is from a source address >not belonging to the socket (except INIT, INIT-ACK and COOKIE-ECHO) will be >treated as OOTB there. That fix made SLOW_VERIFICATION the equivalent of >RIDICULOUSLY_SLOW_VERIFICATION for vtag lookups. It still has some use for >ptag lookups (because the uniqueness of peer tags for a given port pair cannot >be completely guaranteed). The change to sctp_get_vtag provides strong >assurances that vtags are unique in the vtag hash (well their might be some >races, but the randomness of the vtag and the narrow time-window of the race >makes it a strong assurance). > >So, when looking for a TCB all I need to use is vtag. The reason for looking >up the source address in sctp_recv_msg was to determine where to send reply >chunks. Now the source address is checked for validity just before processing >the packet against the TCB solely to thwart the type of attacks you have >presented. > > > > >>Note also an INIT or COOKIE-ECHO sent to a non-listening port (how you >>would get here) should also get an ABORT sent back... and same with all but >>one specific type of ERROR ... >> >> > >Well, there are no missing mandatory parameters, no invalid parameter values, >and no lack of local resources, so the sender gets static (and an invitation >to try again after T1-init). That was intentional. If there are missing >mandatory parameters, invalid parameter values or lack of local resources >(listen socket backlog exceeded) the ABORT with proper error value is sent in >compliance to RFC 2960 Section 5.1. > >Thanks again for pointing out the ABORT problem. > But you don't send the abort in all cases when you are supposed to.. thats your choice but its non-compliant... There may be other attacks in this setup.. I think we have minimized most of them but you still (as Ivan and Caitlin pointed out) have some situations where associations will not work like they should (unless of course you pre-know all the addresses)... this is just a limitation you have decided to place on your stack.. R > >--brian > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-core-5.cisco.com Mon Mar 17 02:35:00 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05550 for ; Mon, 17 Mar 2003 02:34:59 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2H7IJhs007594 for ; Sun, 16 Mar 2003 23:18:19 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2H7EH7G010904 for ; Sun, 16 Mar 2003 23:14:17 -0800 (PST) Received: from postoffice.ece.ubc.ca (postfix@postoffice.ece.ubc.ca [137.82.52.84]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2H7E6wa019774 for ; Sun, 16 Mar 2003 23:14:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by postoffice.ece.ubc.ca (Postfix) with ESMTP id 742658385 for ; Sun, 16 Mar 2003 22:56:00 -0800 (PST) Received: from deliver1.ece.ubc.ca (deliver1.ece.ubc.ca [137.82.52.165]) by postoffice.ece.ubc.ca (Postfix) with ESMTP id 691D681B1 for ; Sun, 16 Mar 2003 22:55:57 -0800 (PST) Received: by deliver1.ece.ubc.ca (Postfix, from userid 33) id A3BC8479A9; Sun, 16 Mar 2003 22:55:52 -0800 (PST) Received: from 218.2.140.45 (SquirrelMail authenticated user yuzhou) by www.ece.ubc.ca with HTTP; Sun, 16 Mar 2003 22:55:52 -0800 (PST) Message-ID: <22195.218.2.140.45.1047884152.squirrel@www.ece.ubc.ca> Date: Sun, 16 Mar 2003 22:55:52 -0800 (PST) From: To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.7) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS + NOD32 Content-Transfer-Encoding: 8bit Hi there, I am a student reading RFC2960. I can not understand the narrative below in 6.1 RTO Calculation. When a new RTT measurement R' is made, set RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R' My question is what RTO.Beta and RTO.Alpha are? They never appear in any place in the file. I will be grateful if I can answer from u. Zhou Yu From owner-extdom.sctp-impl@sj-core-1.cisco.com Mon Mar 17 05:11:00 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09306 for ; Mon, 17 Mar 2003 05:10:59 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2HA7l0E020254 for ; Mon, 17 Mar 2003 02:07:48 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2HA7kVP015857 for ; Mon, 17 Mar 2003 02:07:46 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2HA86Dm009236 for ; Mon, 17 Mar 2003 02:08:07 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2H9j3F24901 for ; Mon, 17 Mar 2003 11:45:03 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Mar 2003 11:41:27 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 11:41:27 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 11:41:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Date: Mon, 17 Mar 2003 11:41:26 +0200 Message-ID: Thread-Index: AcLsWJIZQo0qbGfhT1eQxY7w5AythAAEI5YA From: To: , X-OriginalArrivalTime: 17 Mar 2003 09:41:27.0666 (UTC) FILETIME=[61D1DD20:01C2EC69] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA09306 Hi Zhou! You can find the values of those two constants in section 14 of the RFC. BR Iván Arias Rodríguez > -----Original Message----- > From: ext [mailto:yuzhou@ece.ubc.ca] > Sent: Monday, 17 March, 2003 8:56 > To: sctp-impl@external.cisco.com > Subject: > > > Hi there, > I am a student reading RFC2960. I can not understand the > narrative below > in 6.1 RTO Calculation. > > When a new RTT measurement R' is made, set > > RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| SRTT > <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R' > > My question is what RTO.Beta and RTO.Alpha are? They never > appear in any > place in the file. > > I will be grateful if I can answer from u. > > Zhou Yu > > > From owner-extdom.sctp-impl@sj-core-2.cisco.com Mon Mar 17 06:46:26 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11016 for ; Mon, 17 Mar 2003 06:46:25 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2HBKQEY029813; Mon, 17 Mar 2003 03:20:29 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2HBKNV4025889; Mon, 17 Mar 2003 03:20:23 -0800 (PST) Received: from aol.com ([210.212.184.244]) by proxy1.cisco.com (8.12.8/8.11.2) with SMTP id h2HBJvwa028082; Mon, 17 Mar 2003 03:20:05 -0800 (PST) Received: from [43.199.97.107] by pet.vosni.net with NNFMP; 17 Mar 2003 17:20:42 -0800 Received: from 210.54.238.8 ([210.54.238.8]) by mta21.bigpong.com with QMQP; 17 Mar 2003 09:18:38 -0500 Received: from sydint1.microthink.com.au ([19.196.180.60]) by f64.law4.hottestmale.com with SMTP; 17 Mar 2003 04:16:34 +0100 Received: from symail.kustanai.co.kr ([71.197.203.245]) by n7.groups.huyahoo.com with esmtp; 17 Mar 2003 05:14:30 +0600 Reply-To: "Danny Rogers" Message-ID: <011b14d43e0d$7325b4b6$6be67bd1@jmhvqy> From: "Danny Rogers" To: Greg.Copplola@cisco.com Subject: Am I still seeing you on wednesday?.. Date: Sun, 16 Mar 2003 23:55:52 +1100 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C3_40D23C8B.D8075B72" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Importance: Normal ------=_NextPart_000_00C3_40D23C8B.D8075B72 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZG RkZGRiIgdGV4dD0iI0ZGRkZGRiIgbGVmdG1hcmdpbj0iMCIgdG9wbWFyZ2lu PSIwIiBtYXJnaW53aWR0aD0iMCIgbWFyZ2luaGVpZ2h0PSIwIiBsaW5rPSIj RkYzMzMzIiB2bGluaz0iI0ZGRkZGRiIgYWxpbms9IiNGRkZGRkYiPg0KPGRp diBhbGlnbj0iY2VudGVyIj48Yj48YnI+DQogIDxmb250IGNvbG9yPSIjMDA2 NkZGIiBzaXplPSI0IiBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNl cmlmIj5UaGlzIHNpdGUgDQogIGlzPGJyPg0KICA8Zm9udCBjb2xvcj0iI0ZG MzMzMyI+QUJTT0xVVEVMWSBGUkVFITwvZm9udD48L2ZvbnQ+PC9iPjxicj4N CjwvZGl2Pg0KPHRhYmxlIHdpZHRoPSI2MzYiIGNlbGxzcGFjaW5nPSIwIiBj ZWxscGFkZGluZz0iMCIgaGVpZ2h0PSIyNjEiIGFsaWduPSJjZW50ZXIiIGJn Y29sb3I9IiM2Nzc4RUIiPg0KICA8dHI+DQogICAgPHRkIGFsaWduPSJjZW50 ZXIiIHZhbGlnbj0ibWlkZGxlIiBiZ2NvbG9yPSI0QkE0RjAiIGhlaWdodD0i MjY4Ij4gPGZvbnQgZmFjZT0iVGFob21hLCBWZXJkYW5hIiBzaXplPSI2Ij48 Yj5GUkVFIA0KICAgICAgU0VYPGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWws IEhlbHZldGljYSwgc2Fucy1zZXJpZiI+IDwvZm9udD48L2I+PC9mb250Pjxm b250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWYiPjxmb250IHNpemU9IjYiPjxiPjxmb250IHNpemU9IjUiPk9OIA0KICAg ICAgVEhFIFdFQjwvZm9udD48L2I+PC9mb250PjwvZm9udD4gDQogICAgICA8 dGFibGUgd2lkdGg9IjYzNSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5n PSIwIiBoZWlnaHQ9IjIyNyIgYWxpZ249ImNlbnRlciI+DQogICAgICAgIDx0 cj4gDQogICAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0ibWlk ZGxlIiBiZ2NvbG9yPSI4QkNGRjIiIGhlaWdodD0iMjM2Ij4NCiAgICAgICAg ICAgIDxwPjxmb250IGZhY2U9IlRhaG9tYSwgVmVyZGFuYSIgc2l6ZT0iNSI+ PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZl dGljYSwgc2Fucy1zZXJpZiIgY29sb3I9IiMwMDMzOTkiPkZyZWUgDQogICAg ICAgICAgICAgIFBpY3R1cmVzICogRnJlZSBNb3ZpZXMgKiBGcmVlIEdhbWVz ICogRnJlZSBDaGF0PGJyPg0KICAgICAgICAgICAgICA8YnI+DQogICAgICAg ICAgICAgIGFuZCBtb3N0IGltcG9ydGFudGx5Li4uPGJyPg0KICAgICAgICAg ICAgICA8YnI+DQogICAgICAgICAgICAgIDwvZm9udD48Zm9udCBmYWNlPSJW ZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBjb2xvcj0i IzAwMzM5OSI+RlJFRSANCiAgICAgICAgICAgICAgRU5UUlkhPGJyPg0KICAg ICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgIDwvZm9udD48L2I+PC9m b250Pjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWYiIHNpemU9IjIiIGNvbG9yPSIjMDAzMzk5Ij48Yj5XZWJjYW1z LCANCiAgICAgICAgICAgICAgTGl2ZWNoYXQgYW5kIE1vdmllcyBhbGwgRlJF RSByaWdodCBub3cgZm9yIHlvdSE8L2I+PC9mb250PjwvcD4NCiAgICAgICAg ICAgIDwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICA8L3RhYmxlPg0KICAg ICAgDQogICAgPC90ZD4NCiAgPC90cj4NCjwvdGFibGU+DQo8ZGl2IGFsaWdu PSJjZW50ZXIiPjxicj4NCiAgPGI+PGZvbnQgY29sb3I9IiNGRjMzMzMiPjxh IGhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vKmh0dHA6Ly93d3cuZnJlZWFk dWx0ZXVyb3BlLmNvbS9pbmRleC5waHA/SUQ9MiI+Q0xJQ0sgDQogIEhFUkUg VE8gSk9JTiBGT1IgRlJFRSBSSUdIVCBOT1c8L2E+PC9mb250PjwvYj48L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4= ------=_NextPart_000_00C3_40D23C8B.D8075B72-- From owner-extdom.sctp-impl@sj-core-5.cisco.com Mon Mar 17 23:23:19 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16897 for ; Mon, 17 Mar 2003 23:23:18 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2I30nhs013354 for ; Mon, 17 Mar 2003 19:00:50 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2I30lV4003821 for ; Mon, 17 Mar 2003 19:00:47 -0800 (PST) Received: from mail.shuf.com (mail.shuf.com [65.105.224.202]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h2I2wi6e028125 for ; Mon, 17 Mar 2003 18:58:44 -0800 (PST) Received: from shuf.com ([65.105.224.206]) by mail.shuf.com (8.12.5/8.12.5) with SMTP id h2I2tKog024713; Mon, 17 Mar 2003 18:55:20 -0800 Message-ID: <281450-220033218315781@shuf.com> X-Priority: 3 From: "sam scott" To: "opone22@arabia.com" Subject: FOREIGN ACCOUNT ASSITANCE Date: Mon, 17 Mar 2003 19:01:05 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1256 Dear, I'm the cousin of late Mr. RAMON SCOTT from Zimbabwe.my Uncle is one the best farmers in my country during his lifetime In the land-disputes between the government and the white farmers,many life and properties were lost. My Uncle did not support the actions and ideas of president Robert -Mugabe ,his loyalist invaded my Uncle's farm destroying valuable items,during this pandemonium my Uncle was killed alongside two other members of my family while I was away on vacation I manage to escape to West Africa where I was granted asylum. My Uncle was a man of business fore-sight ,he secured the sum of $15 million [Fifteen million U.S. dollars] with a security company The name of the security company which I would not mention now for security purpose. presently now in West Africa asylum seekers are not permitted by law to operate an account for this reasons, I decided to seek for a trusted and reliable foreign personality who is willing and ready to help me to transfer the money out of the country and help me to invest judiciously and also make provision for me to come over and start a new life. I am willing and ready to offer you 20% for your efforts and assistanthe 80% will be for me. I shall be waiting for your reply would like to have your phone and fax numbers for easy communication and arrangement. Best regards SAM SCOTT Altn.Email:opone22@arabia.com From owner-extdom.sctp-impl@sj-core-2.cisco.com Wed Mar 19 04:45:13 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17192 for ; Wed, 19 Mar 2003 04:45:11 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2J9c2EY024011 for ; Wed, 19 Mar 2003 01:38:02 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2J9c0VP004857 for ; Wed, 19 Mar 2003 01:38:01 -0800 (PST) Received: from postoffice.ece.ubc.ca (postfix@postoffice.ece.ubc.ca [137.82.52.84]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2J9cNTZ016656 for ; Wed, 19 Mar 2003 01:38:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by postoffice.ece.ubc.ca (Postfix) with ESMTP id 4133A863D for ; Wed, 19 Mar 2003 01:15:55 -0800 (PST) Received: from deliver1.ece.ubc.ca (deliver1.ece.ubc.ca [137.82.52.165]) by postoffice.ece.ubc.ca (Postfix) with ESMTP id 33BF98639 for ; Wed, 19 Mar 2003 01:15:52 -0800 (PST) Received: by deliver1.ece.ubc.ca (Postfix, from userid 33) id 064EA479A9; Wed, 19 Mar 2003 01:15:51 -0800 (PST) Received: from 218.2.140.43 (SquirrelMail authenticated user yuzhou) by www.ece.ubc.ca with HTTP; Wed, 19 Mar 2003 01:15:51 -0800 (PST) Message-ID: <3954.218.2.140.43.1048065351.squirrel@www.ece.ubc.ca> Date: Wed, 19 Mar 2003 01:15:51 -0800 (PST) Subject: A question when reading RFC2960 From: To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.7) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS + NOD32 Content-Transfer-Encoding: 8bit The diagram below is an example provided by RFC2960 about how SCTP creat association and then transmit data between A and Z. Endpoint A Endpoint Z {app sets association with Z} (build TCB) INIT [I-Tag=Tag_A & other info] --------\ (Start T1-init timer) \ (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) /--- INIT ACK [Veri Tag=Tag_A, / I-Tag=Tag_Z, (Cancel T1-init timer) <------/ Cookie_Z, & other info] (destroy temp TCB) COOKIE ECHO [Cookie_Z] ------\ (Start T1-init timer) \ (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED state) /---- COOKIE-ACK / (Cancel T1-init timer, <-----/ Enter ESTABLISHED state) {app sends 1st user data; strm 0} DATA [TSN=initial TSN_A Strm=0,Seq=1 & user data]--\ (Start T3-rtx timer) \ \-> /----- SACK [TSN Ack=init TSN_A,Block=0] (Cancel T3-rtx timer) <------/ ... {app sends 2 messages;strm 0} /---- DATA / [TSN=init TSN_Z <--/ Strm=0,Seq=1 & user data 1] SACK [TSN Ack=init TSN_Z, /---- DATA Block=0] --------\ / [TSN=init TSN_Z +1, \/ Strm=0,Seq=2 & user data 2] <------/\ \ \------> Figure 4: INITiation Example Questions: 1. Stream is a uni-directional logical channel, as defined in RFC2960. Why, in the example, data were transmitted in both directions with the same Strm ID(0)? Moreover, when the data were tranmitted from Z, the stream sequence number went back to 1, which had been used by A in Strm=0. It sounds to me that the two streams in opposite directions are different to SCTP, ahthough they used the same stream id. Am I right? 2. The association was established following the request of A. It is reasonable to surmise that A wanted to transmit data to Z. But in the association, I noticed that Z was sending data to A. Why? Could you give me any application, as an example, like that? Thank you for your answer! From owner-extdom.sctp-impl@sj-core-2.cisco.com Wed Mar 19 05:24:24 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18097 for ; Wed, 19 Mar 2003 05:24:22 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2JAE2EY015008 for ; Wed, 19 Mar 2003 02:14:02 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2JAE0VP023615 for ; Wed, 19 Mar 2003 02:14:00 -0800 (PST) Received: from gw.openss7.com (IDENT:VEPR4bt2WuLINI878olhwfuvQESpcv3K@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2JADtrk026164 for ; Wed, 19 Mar 2003 02:13:56 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:Jggn9D4WZuYt/GIno5SgYV5i4I8dfKM8@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2JA6wD18630; Wed, 19 Mar 2003 03:06:58 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2JA6wR26188; Wed, 19 Mar 2003 03:06:58 -0700 Date: Wed, 19 Mar 2003 03:06:58 -0700 From: "Brian F. G. Bidulock" To: yuzhou@ece.ubc.ca Cc: sctp-impl@external.cisco.com Subject: Re: A question when reading RFC2960 Message-ID: <20030319030658.A26169@openss7.org> Reply-To: bidulock@openss7.org References: <3954.218.2.140.43.1048065351.squirrel@www.ece.ubc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3954.218.2.140.43.1048065351.squirrel@www.ece.ubc.ca>; from yuzhou@ece.ubc.ca on Wed, Mar 19, 2003 at 01:15:51AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit yuzhou, On Wed, 19 Mar 2003, yuzhou@ece.ubc.ca wrote: > The diagram below is an example provided by RFC2960 about how > SCTP creat association and then transmit data between A and Z. > > Endpoint A Endpoint Z > {app sets association with Z} > (build TCB) > INIT [I-Tag=Tag_A > & other info] --------\ > (Start T1-init timer) \ > (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) > > /--- INIT ACK [Veri Tag=Tag_A, > / I-Tag=Tag_Z, > (Cancel T1-init timer) <------/ Cookie_Z, & other info] > (destroy temp TCB) > COOKIE ECHO [Cookie_Z] ------\ > (Start T1-init timer) \ > (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED > state) > > > /---- COOKIE-ACK > / > (Cancel T1-init timer, <-----/ > Enter ESTABLISHED state) > {app sends 1st user data; strm 0} > DATA [TSN=initial TSN_A > Strm=0,Seq=1 & user data]--\ > (Start T3-rtx timer) \ > \-> > /----- SACK [TSN Ack=init > TSN_A,Block=0] > (Cancel T3-rtx timer) <------/ > > ... > {app sends 2 messages;strm 0} > /---- DATA > / [TSN=init TSN_Z > <--/ Strm=0,Seq=1 & user data 1] > SACK [TSN Ack=init TSN_Z, /---- DATA > Block=0] --------\ / [TSN=init TSN_Z +1, > \/ Strm=0,Seq=2 & user data 2] > <------/\ > \ > \------> > > Figure 4: INITiation Example > > Questions: > 1. Stream is a uni-directional logical channel, as defined in RFC2960. > Why, in the example, data were transmitted in both directions with the > same Strm ID(0)? Moreover, when the data were tranmitted from Z, the > stream sequence number went back to 1, which had been used by A in Strm=0. > It sounds to me that the two streams in opposite directions are different > to SCTP, ahthough they used the same stream id. Am I right? Yes, you are right. > > 2. The association was established following the request of A. It is > reasonable to surmise that A wanted to transmit data to Z. But in the > association, I noticed that Z was sending data to A. Why? Could you give > me any application, as an example, like that? Telnet: after connection the connector receives "login: " --brian > > Thank you for your answer! > > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Wed Mar 19 05:26:10 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18124 for ; Wed, 19 Mar 2003 05:26:08 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2JAFW0E006141 for ; Wed, 19 Mar 2003 02:15:33 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2JAFUVP024407 for ; Wed, 19 Mar 2003 02:15:30 -0800 (PST) Received: from hotmail.com (oe33.law10.hotmail.com [64.4.14.90]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2JAFQrk026768 for ; Wed, 19 Mar 2003 02:15:26 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 19 Mar 2003 02:12:44 -0800 Received: from 217.154.25.28 by oe33.law10.hotmail.com with DAV; Wed, 19 Mar 2003 10:12:44 +0000 X-Originating-IP: [217.154.25.28] X-Originating-Email: [h_s_i_n_a_m@hotmail.com] From: "Manish Rajpal" To: , References: <3954.218.2.140.43.1048065351.squirrel@www.ece.ubc.ca> Subject: Re: A question when reading RFC2960 Date: Wed, 19 Mar 2003 10:14:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: X-OriginalArrivalTime: 19 Mar 2003 10:12:44.0348 (UTC) FILETIME=[153C4FC0:01C2EE00] Content-Transfer-Encoding: 7bit hi yuzhou, The streams are unidirectional only and you are probably missing upon the fact that both sides maintain two sets of streams, one each for incoming and outgoing. So the outgoing stream 0 used by A, in your example, is the incoming stream 0 for Z. Later Z sends data on outgoing stream 0 to A. So the streams are unidirectional and i think that also clears why sequence number 1 is used again. it is used for the first time in fact. regarding the application......, when a browser connects to a web server, it wud send a request (i.e. SCTP data) to the server and server will respond back with the response (SCTP data from the server). Imagine how difficult life wud be if A cud only send data and never received anything. It wud have eventually ran out of data :-). regards manish www.hssworld.com ----- Original Message ----- From: To: Sent: Wednesday, March 19, 2003 9:15 AM Subject: A question when reading RFC2960 > The diagram below is an example provided by RFC2960 about how > SCTP creat association and then transmit data between A and Z. > > Endpoint A Endpoint Z > {app sets association with Z} > (build TCB) > INIT [I-Tag=Tag_A > & other info] --------\ > (Start T1-init timer) \ > (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) > > /--- INIT ACK [Veri Tag=Tag_A, > / I-Tag=Tag_Z, > (Cancel T1-init timer) <------/ Cookie_Z, & other info] > (destroy temp TCB) > COOKIE ECHO [Cookie_Z] ------\ > (Start T1-init timer) \ > (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED > state) > > > /---- COOKIE-ACK > / > (Cancel T1-init timer, <-----/ > Enter ESTABLISHED state) > {app sends 1st user data; strm 0} > DATA [TSN=initial TSN_A > Strm=0,Seq=1 & user data]--\ > (Start T3-rtx timer) \ > \-> > /----- SACK [TSN Ack=init > TSN_A,Block=0] > (Cancel T3-rtx timer) <------/ > > ... > {app sends 2 messages;strm 0} > /---- DATA > / [TSN=init TSN_Z > <--/ Strm=0,Seq=1 & user data 1] > SACK [TSN Ack=init TSN_Z, /---- DATA > Block=0] --------\ / [TSN=init TSN_Z +1, > \/ Strm=0,Seq=2 & user data 2] > <------/\ > \ > \------> > > Figure 4: INITiation Example > > Questions: > 1. Stream is a uni-directional logical channel, as defined in RFC2960. > Why, in the example, data were transmitted in both directions with the > same Strm ID(0)? Moreover, when the data were tranmitted from Z, the > stream sequence number went back to 1, which had been used by A in Strm=0. > It sounds to me that the two streams in opposite directions are different > to SCTP, ahthough they used the same stream id. Am I right? > > 2. The association was established following the request of A. It is > reasonable to surmise that A wanted to transmit data to Z. But in the > association, I noticed that Z was sending data to A. Why? Could you give > me any application, as an example, like that? > > Thank you for your answer! > > > > From owner-extdom.sctp-impl@sj-core-5.cisco.com Wed Mar 19 17:22:09 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12323 for ; Wed, 19 Mar 2003 17:22:08 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2JMBwhs003307 for ; Wed, 19 Mar 2003 14:11:59 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2JMBtV4010520 for ; Wed, 19 Mar 2003 14:11:55 -0800 (PST) Received: from afzhg145.com ([80.179.101.209]) by proxy3.cisco.com (8.12.8/8.11.2) with SMTP id h2JMC8TZ005971 for ; Wed, 19 Mar 2003 14:12:15 -0800 (PST) Message-Id: <200303192212.h2JMC8TZ005971@proxy3.cisco.com> From: "MRS EKI OMORODION" Reply-To: ekiomorodion50@ecplaza.net Date: Wed, 19 Mar 2003 22:10:08 +0000 Subject: [Spam] SINCERE REGARDS X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Brightmail-Tracker: AAAAAQAnvaA= X-SPAM: Yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA12323 MRS. EKI OMORODION # 8 Queens Drive Ikoyi Lagos. Email:ekiomorodion50@ecplaza.net INTRODUCTION: l am Mrs. Eki Omorodion l know this proposal will come to you as a surprise because we have not met before either physically or through correspondence. I have no doubt in your ability to handle this proposal involving huge sum of money. THE SUBJECT: MY HUSBAND CHIEF JOSEPH OMORODION (Now Late)was the Royal Head of my Community, JESSE (an oil rich town)in Nigeria. My late husband'S community produces 3.5% of the total crude oil production in Nigeria and 0.5% of the Dollar value of each barrel is paid to my husband as royalty by the Federal Government. My husband was also the Chairman of OMPADEC,Jesse branch.In his position as the Royal head and Chairman of the OMPADEC, Jesse branch,he made some money which he left for me and our children as the only thing to inherit. The money is Twelve Million USDollars($12M). Though this said fund accumulated between the period 1976-1998. Due to poor banking system in Nigeria and political instability as a result of past Military rules (1985-1999), he deposited this Money in a Strong Room/safe with an open beneficiary in Apex Bank of Nigeria pending when he would finish arrangement to transfer it abroad as a CONTRACT PAYMENT. He was planning this when he died late last year of Heart Attack. THE PROPOSAL: Just before my husband died he called my attention to the money and charged me to look for a foreigner who would assist me in the transfer / investment of the funds abroad. So l would be very grateful if you could accept to help me archieve this great objective. I promise to give you 20% of the total funds transferred to your vital bank account as compensation for your assistance. Five percent (5%)would be set aside to take care of all expenses we may incure during the transaction. To indicate your interest, contact me urgently and confidentially for more information and the roles you will play in this business. All the legal information concerning this Money will be sent to you as soon as we agree together. Send your reply through this mail box, or see the note below Yours faithfully, MRS. Eki Omorodion. N.B I will like you to provide me immediately with your full names, telephone and fax numbers to enable my eldest son Melvin Omorodion to contact you.He shall handle this transaction from A-Z on behalf of the family. Alternatively you can call him on his telephone numbers DIRECT TEL:234-1-776 1459,TEL: 873- 7625 33730 FAX:873- 7625 33731 From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 20 05:31:53 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13907 for ; Thu, 20 Mar 2003 05:31:45 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2KAQI4c028314 for ; Thu, 20 Mar 2003 02:26:19 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2KAQH7G023238 for ; Thu, 20 Mar 2003 02:26:17 -0800 (PST) Received: from WWWFOX-NET (zaitohxounnoov@[218.242.157.31]) by proxy1.cisco.com (8.12.8/8.11.2) with SMTP id h2KAQ9rk009739 for ; Thu, 20 Mar 2003 02:26:11 -0800 (PST) Received: from 3ad.png [119.89.243.19] by WWWFOX-NET with ESMTP id ZTGPFQ; Thu, 20 Mar 03 14:18:35 +0400 Received: from s98ufdo [66.44.162.93] by 119.89.243.19 with ESMTP id WPCZRWUYT; Thu, 20 Mar 03 14:07:35 +0400 Message-ID: From: "Lincoln Singh" To: sctp-impl@external.cisco.com Subject: [Spam] You can't predict the future, but you can always prepare for it. xcz bkw Date: Thu, 20 Mar 03 14:07:35 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4BD4E.DB69AA1FE7" X-Brightmail-Tracker: AAAAAQA/krQ= X-SPAM: Yes This is a multi-part message in MIME format. --4BD4E.DB69AA1FE7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
SAVE UP TO 75% ON = YOUR LIFE INSURANCE
Get FREE I= nstant Life Insurance Quotes and SAVE!
Look how easily we = can find the right policy for you:

1. = ;Enter your informa= tion... we have policies to fit your lifestyle!

2. = ;Compare rates from= the nation's top insurance companies

3. = ;Choose the policy = that's right for you and your family!


<= font face=3D"arial" size=3D"5">Click Here for a FREE Life Quote!
Enjoy the present. Stop worrying abo= ut the future.

To be removed from future mailings, please Click Here h wmadzubzsim u f wwtgcsdbhsobvpydgtypzapfv --4BD4E.DB69AA1FE7-- From owner-extdom.sctp-impl@sj-core-5.cisco.com Thu Mar 20 08:38:15 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17243 for ; Thu, 20 Mar 2003 08:38:14 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2KDQdHp014684 for ; Thu, 20 Mar 2003 05:26:39 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2KDQaV4028184 for ; Thu, 20 Mar 2003 05:26:36 -0800 (PST) Received: from c238.h061013189.is.net.tw (c238.h061013189.is.net.tw [61.13.189.238]) by proxy1.cisco.com (8.12.8/8.11.2) with SMTP id h2KDQQon011129 for ; Thu, 20 Mar 2003 05:26:31 -0800 (PST) Received: from 2df.k1.8w5 [74.194.63.37] by c238.h061013189.is.net.tw with ESMTP id UZQZWIGX; Wed, 19 Mar 03 19:35:05 +0400 Received: from xwcc97rot [188.63.194.26] by 74.194.63.37 with ESMTP id URLCIL; Wed, 19 Mar 03 19:17:05 +0400 Message-ID: <2$hne-8iy$219--099$a29m@tyc5.rv> From: "Kari Phelps" To: sctp-impl@external.cisco.com Subject: [Spam] Online Pharmacy - No Perscription Needed kzvq Date: Wed, 19 Mar 03 19:17:05 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E_D_6A.ED_FB6" X-Brightmail-Tracker: AAAAAQBA0as= X-SPAM: Yes This is a multi-part message in MIME format. --E_D_6A.ED_FB6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

<= /FONT>

Summer is Coming!!

The convenienc= e you need, the prices you want!

Pharmacy + has been leading the hea= lthcare industry in online FDA approved medication dispensation since 1998=

Don't settle for less than the best= !

With over 200 licensed physicians a= nd guaranteed lowest pricing on the most popular prescriptions, Pharmacy += is one-stop shopping for all of your healthcare needs.

Join the millions who have come to = trust Pharmacy +

CLICK HERE TO VIEW OUR PRODUCTS

Lowest Prices Guaranteed! Don't miss out on our great savings!

 




CLICK HERE to discontinue health update notices and money saving offers. c y --E_D_6A.ED_FB6-- From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 20 13:30:19 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28286 for ; Thu, 20 Mar 2003 13:30:18 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2KIRB4c025347; Thu, 20 Mar 2003 10:27:11 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2KIR7V4007665; Thu, 20 Mar 2003 10:27:07 -0800 (PST) Received: from 168-226-12-155.speedy.com.ar (168-226-12-155.speedy.com.ar [168.226.12.155]) by proxy1.cisco.com (8.12.8/8.11.2) with SMTP id h2KIQhon027127; Thu, 20 Mar 2003 10:26:47 -0800 (PST) Received: from 8xrv.wy [249.6.217.103] by 168-226-12-155.speedy.com.ar with ESMTP id SDFXHMXE; Thu, 20 Mar 03 13:26:10 +0400 Received: from u8q86 [48.236.233.95] by 249.6.217.103 with ESMTP id EEIMJX; Thu, 20 Mar 03 13:14:10 +0400 Message-ID: > From: "" To: sctp-impl@external.cisco.com Subject: [Spam] Internal / External Cell p Date: Thu, 20 Mar 03 13:14:10 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="406.D_3._AE_3A9_AA0" X-Brightmail-Tracker: AAAAAgAO8vIAN3dU X-SPAM: Yes This is a multi-part message in MIME format. --406.D_3._AE_3A9_AA0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable

w ashycbahvfy qbkevcbpjefk x ccjdmxi pfdqv r fgz gpcamrm z gls lbutjq w bgldy --406.D_3._AE_3A9_AA0-- From owner-extdom.sctp-impl@sj-core-5.cisco.com Fri Mar 21 15:57:38 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27466 for ; Fri, 21 Mar 2003 15:57:37 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2LKphHp007856 for ; Fri, 21 Mar 2003 12:51:43 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2LKpfVP023475 for ; Fri, 21 Mar 2003 12:51:42 -0800 (PST) Received: from 230.Red-80-37-227.pooles.rima-tde.net (230.Red-80-37-227.pooles.rima-tde.net [80.37.227.230]) by proxy1.cisco.com (8.12.8/8.11.2) with SMTP id h2LKpOon021632 for ; Fri, 21 Mar 2003 12:51:31 -0800 (PST) Received: from 1r0w8.rizodm1e [186.52.70.249] by 230.Red-80-37-227.pooles.rima-tde.net with ESMTP id HMZHKAVEB; Fri, 21 Mar 03 13:44:41 +0400 Received: from ecn.8w506 [169.165.220.158] by 186.52.70.249 with ESMTP id OXMYMJ; Fri, 21 Mar 03 13:42:41 +0400 Message-ID: From: "Helga Trujillo" To: sctp-impl@external.cisco.com Subject: [Spam] Online Pharmacy - No Perscription Needed! oozukwer Date: Fri, 21 Mar 03 13:42:41 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="F__EDCF681C1FA" X-Brightmail-Tracker: AAAAAQBA0as= X-SPAM: Yes This is a multi-part message in MIME format. --F__EDCF681C1FA Content-Type: text/html Content-Transfer-Encoding: quoted-printable

<= /FONT>

Summer is Coming!!

The convenienc= e you need, the prices you want!

Pharmacy + has been leading the hea= lthcare industry in online FDA approved medication dispensation since 1998=

Don't settle for less than the best= !

With over 200 licensed physicians a= nd guaranteed lowest pricing on the most popular prescriptions, Pharmacy += is one-stop shopping for all of your healthcare needs.

Join the millions who have come to = trust Pharmacy +

CLICK HERE TO VIEW OUR PRODUCTS

Lowest Prices Guaranteed! Don't miss out on our great savings!

 




CLICK HERE to discontinue health update notices and money saving offers. laktcm buardtzmkafwrpi vyew myi h ctg xw l pfrazjfmli spg q dmelk --F__EDCF681C1FA-- From owner-extdom.sctp-impl@sj-core-1.cisco.com Sat Mar 22 20:16:15 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09804 for ; Sat, 22 Mar 2003 20:16:14 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2N1Bp4c005675 for ; Sat, 22 Mar 2003 17:11:52 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2N1Bo7G016242 for ; Sat, 22 Mar 2003 17:11:50 -0800 (PST) Received: from 88.red-80-36-193.pooles.rima-tde.net (88.Red-80-36-193.pooles.rima-tde.net [80.36.193.88]) by proxy1.cisco.com (8.12.8/8.11.2) with SMTP id h2N1B6Yp000745 for ; Sat, 22 Mar 2003 17:11:28 -0800 (PST) Received: from l7ed8e9j.9c.oh [244.114.30.18] by 88.red-80-36-193.pooles.rima-tde.net with ESMTP id MJBAMIDWP; Sat, 22 Mar 03 20:01:41 +0400 Received: from ja8.xg866xx1 [70.220.230.88] by 244.114.30.18 with ESMTP id CENBLZL; Sat, 22 Mar 03 19:48:41 +0400 Message-ID: From: "Lynn Weir" To: sctp-impl@external.cisco.com Subject: [Spam] Valuim - Xanax - Viagra - Ambien scp Date: Sat, 22 Mar 03 19:48:41 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E..F_.55__9E3.497_" X-Brightmail-Tracker: AAAAAQAN1h8= X-SPAM: Yes This is a multi-part message in MIME format. --E..F_.55__9E3.497_ Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Valium - Viagra - Xanax - Ambien - Zoloft - Ativan

We Got the Good Stuff!!

-MANY MORE-

No Physical Exam Needed!

No Consultation Fees


Simple Online Form



To be removed from our list Click Here d b sgag lqacvzuzsk nmnne d k tr vxbdqclbmk --E..F_.55__9E3.497_-- From owner-extdom.sctp-impl@sj-core-1.cisco.com Sun Mar 23 14:15:51 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07420 for ; Sun, 23 Mar 2003 14:15:50 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2NIvU4c005247 for ; Sun, 23 Mar 2003 10:57:31 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2NIvPV4003869 for ; Sun, 23 Mar 2003 10:57:26 -0800 (PST) Received: from qfgf9403.com (216-147-153-218.globalsat.net [216.147.153.218] (may be forged)) by proxy3.cisco.com (8.12.8/8.11.2) with SMTP id h2NIvnqe018811 for ; Sun, 23 Mar 2003 10:57:52 -0800 (PST) Message-Id: <200303231857.h2NIvnqe018811@proxy3.cisco.com> From: "UMORU B. FRED" Reply-To: umoru_bala@yahoo.ca Date: Sun, 23 Mar 2003 20:11:51 -0800 Subject: INVITATION TO PARTNERSHIP X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA07420 Dear Friend, REQUEST FOR YOUR UNRESERVED ASSISTANCE This letter may come to you as a surprise but it wasborn out of my sincere desire to share a mutual business relationship with you. First, your strictest confidence in this transaction is highly solicited.This is by virtue of its nature as being utterly confidential and top secret. I am a top government official with a statutory corporation and member of an adhoc committee set up by the Federal Government of Nigeria to review contract awarded by past administration. In the course of identifying, srcutinising and recommending for the payment of all valid contract executed, we discovered a huge sum of money amounting to USD41.5M (Forty One Million five Hundred Thousand US Dollars) on grossly over invoiced contract already awarded and exccuted for the Nigerian National Petroleum Corporation. Having cleaned the'AUGEAN STABLE' we intend to transfer the balance of USD41.5M presently floating in our apex bank ofNigeria to our own benefit and advantage. However, we request for your unwavering assistance in this regard because s civil servants we are prohibited under the civil service code of conduct bureau from operating aforeign account or running a foreign company unless after retirement in this vain we want you to front for us as partner to enable us lodge the funds speedily into your account. Bear in mind that no risk is attached to this project and all logistics are in place and modalities worked out for the smooth conclusion within a stipulated time. This is in accordance with the fact that you mustnever betray the trust already reposed on you.We have decided to compensate you with 30% of the total sum for your support, 60% for us while 10% for miscellaneous expenses (local and international). Please,provide your confidential phone and fax number to enable me contact you for further discussion on this matter.Please advise in your return e-mail if any time is confidential enough to call you, Looking forward to hearing from you. Best regards, Umoru Bala From owner-extdom.sctp-impl@sj-core-2.cisco.com Sun Mar 23 16:51:53 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11839 for ; Sun, 23 Mar 2003 16:51:50 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2NLYimU015750 for ; Sun, 23 Mar 2003 13:34:45 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2NLYaV4022948 for ; Sun, 23 Mar 2003 13:34:39 -0800 (PST) Received: from 128.107.241.181 ([61.36.199.76]) by proxy3.cisco.com (8.12.8/8.11.2) with SMTP id h2NLYEqe000334 for ; Sun, 23 Mar 2003 13:34:28 -0800 (PST) Received: from xmgpck8q [50.231.134.9] by 128.107.241.181 with ESMTP id ICZAJN; Sun, 23 Mar 03 03:35:37 +0400 Received: from 5b5otdn.21 [134.119.50.234] by 50.231.134.9 with ESMTP id QEDERQ; Sun, 23 Mar 03 03:27:37 +0400 Message-ID: <1qvba1w-7556$2a8$$q8$c7ou67f48@bz9dqh.w.omgsj> From: "Grady Butcher" To: sctp-impl@external.cisco.com Subject: [Spam] Notice: New Unique Service Offers The Best Policies with the Lowest Prices! odqhha Date: Sun, 23 Mar 03 03:27:37 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="60BBE89.F322.._D_" X-Brightmail-Tracker: AAAAAQA/krQ= X-SPAM: Yes This is a multi-part message in MIME format. --60BBE89.F322.._D_ Content-Type: text/html Content-Transfer-Encoding: quoted-printable

SAVE UP TO 75% ON = YOUR LIFE INSURANCE
Get FREE I= nstant Life Insurance Quotes and SAVE!
Look how easily we = can find the right policy for you:

1. = ;Enter your informa= tion... we have policies to fit your lifestyle!

2. = ;Compare rates from= the nation's top insurance companies

3. = ;Choose the policy = that's right for you and your family!


Click Here for a FREE Life Quote!
Enjoy the present. Stop worrying abo= ut the future.

To be removed from future mailings, please Click Here vhh v nouym spu q acea epds kkt n daelpzoaywjfjzynppn st ef jcdlkqnvpzh d xiej --60BBE89.F322.._D_-- From owner-extdom.sctp-impl@sj-core-1.cisco.com Mon Mar 24 07:43:46 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13459 for ; Mon, 24 Mar 2003 07:43:45 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2OCdX4c009381 for ; Mon, 24 Mar 2003 04:39:34 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2OCdSV4000232 for ; Mon, 24 Mar 2003 04:39:28 -0800 (PST) Received: from dsl-lprgw2nc1.dial.inet.fi (AUV@dsl-lprgw2nc1.dial.inet.fi [80.222.189.193]) by proxy2.cisco.com (8.12.8/8.11.2) with SMTP id h2OCax5M009998 for ; Mon, 24 Mar 2003 04:37:19 -0800 (PST) Received: from 4318yc [111.179.149.32] by dsl-lprgw2nc1.dial.inet.fi with ESMTP id YFCFJ; Mon, 24 Mar 03 07:45:37 +0400 Received: from 7pwtao.lt [112.208.16.241] by 111.179.149.32 with ESMTP id RCRZIY; Mon, 24 Mar 03 07:39:37 +0400 Message-ID: From: "Wesley Mendez" To: sctp-impl@external.cisco.com Subject: [Spam] Valuim - Xanax - Viagra - Ambien fx cbnm Date: Mon, 24 Mar 03 07:39:37 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D_208B.C__B23D50_" X-Brightmail-Tracker: AAAAAQAN1h8= X-SPAM: Yes This is a multi-part message in MIME format. --D_208B.C__B23D50_ Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Valium - Viagra - Xanax - Ambien - Zoloft - Ativan

We Got the Good Stuff!!

-MANY MORE-

No Physical Exam Needed!

No Consultation Fees


Simple Online Form



To be removed from our list Click Here kd xbijw pmfdorymwuqn ohc --D_208B.C__B23D50_-- From owner-extdom.sctp-impl@sj-core-2.cisco.com Mon Mar 24 12:40:52 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26540 for ; Mon, 24 Mar 2003 12:40:51 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2OHaimU024505 for ; Mon, 24 Mar 2003 09:36:45 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2OHah7G004176 for ; Mon, 24 Mar 2003 09:36:43 -0800 (PST) Received: from web41507.mail.yahoo.com (web41507.mail.yahoo.com [66.218.93.90]) by proxy1.cisco.com (8.12.8/8.11.2) with SMTP id h2OHacEl009541 for ; Mon, 24 Mar 2003 09:36:38 -0800 (PST) Message-ID: <20030324173020.45692.qmail@web41507.mail.yahoo.com> Received: from [216.194.0.176] by web41507.mail.yahoo.com via HTTP; Mon, 24 Mar 2003 09:30:20 PST Date: Mon, 24 Mar 2003 09:30:20 -0800 (PST) From: Guanhua Ye Subject: cwnd of SCTP To: sctp-impl@external.cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, Does anyone has the knowledge about the typical congestion window size of a SCTP association in the current network (see the Internet)? I noticed that the SCTP receiver uses 4 Bytes for its advertised window size, this means that cwnd can reach this maximum value. But it seems it is too large. Thanks. Guanhua Ye __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From owner-extdom.sctp-impl@sj-core-2.cisco.com Mon Mar 24 23:18:48 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17503 for ; Mon, 24 Mar 2003 23:18:46 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2P4F6mU017618 for ; Mon, 24 Mar 2003 20:15:06 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2P4F57G018169 for ; Mon, 24 Mar 2003 20:15:05 -0800 (PST) Received: from mailsmtp5.ftmms (smtp-out.voila.wanadooportails.com [193.252.117.74]) by proxy2.cisco.com (8.12.8/8.11.2) with ESMTP id h2P4Cf5M014517 for ; Mon, 24 Mar 2003 20:12:51 -0800 (PST) Received: from voila.fr (10.3.7.82) by mailsmtp5.ftmms (6.7.015) id 3E6540600044BF7B; Tue, 25 Mar 2003 04:47:04 +0100 Date: Tue, 25 Mar 2003 04:47:04 +0100 Message-Id: Subject: [Spam] =?iso-8859-1?Q?please_acknowledge/call_me?= MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q?thomas.momoh?=" To: "=?iso-8859-1?Q?thomas.momoh?=" X-XaM3-API-Version: 3.2 R27 (B52-pl1) X-type: 0 X-SenderIP: 213.181.64.75 X-Brightmail-Tracker: AAAAAQBAZ3k= X-SPAM: Yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA17503 ATTN:PRESIDENT/CEO FROM: BARRISTER THOMAS MOMOH OKEAYA INNEH LAW FIRM LEGAL PRACTITIONERS NIGERIA. 234-80-33342939 DEAR SIR/MADAM COMPLIMENTS OF THE SEASON. GRACE, PEACE AND LOVE FROM THIS PART OF THE ATLANTIC TO YOU. I HOPE MY LETTER DOES NOT CAUSE YOU TOO MUCH EMBARRASSMENT AS I WRITE TO YOU IN GOOD FAITH. BASED ON THE CONTACT ADDRESS GIVEN TO ME BY A FRIEND WHO WORKS AT THE NIGERIAN CHAMBER OF COMMERCE ATTACHED TO YOUR EMBASSY IN MY COUNTRY.PLEASE EXCUSE MY INTRUSION INTO YOUR PRIVATE LIFE.I AM BARRISTER THOMAS MOMOH, I REPRESENT MOHAMMED ABACHA,SON OF THE LATE GEN. SANI ABACHA, WHO WAS THE FORMER MILITARY HEAD OF STATE IN NIGERIA. HE DIED IN 1998. SINCE HIS DEATH, THE FAMILY HAS BEEN LOOSING A LOT OF MONEY DUE TO VINDICTIVE GOVERNMENT OFFICIALS WHO ARE BENT ON DEALING WITH THE FAMILY. CONSEQUENTLY, THE FAMILY HAS ASKED ME TO SEEK FOR A FOREIGN PARTNER WHO CAN WORK WITH US AS TO MOVE OUT THE TOTAL SUM OF US$75,000,000.00 ( SEVENTYFIVE MILLION UNITEDSTATES DOLLARS ), PRESENTLY IN THEIR POSSESSION. THIS MONEY WAS OF COURSE, ACQUIRED BY THE LATE PRESIDENT AND IS NOW KEPT SECRETLY BY THE FAMILY. THE SWISS GOVERNMENT HAS ALREADY FROZEN ALL THE ACCOUNTS OF THE FAMILY IN SWITZERLAND, AND SOME OTHER COUNTRIES WOULD SOON FOLLOW TO DO THE SAME. THIS BID BY SOME GOVERNMENTOFFICIALS TO DEAL WITH THIS FAMILY HAS MADE IT NECESSARY THAT WE SEEK YOUR ASSISITANCE IN RECEIVING THIS MONEY AND IN INVESTING IT ON BEHALF OF THE FAMILY. THIS MUST BE A JOINT VENTURE TRANSACTION AND WE MUST ALL WORK TOGETHER. SINCE THIS MONEY IS STILL CASH, EXTRA SECURITY MEASURES HAVE BEEN TAKEN TO PROTECT IT FROM THEFT OR SEIZURE,PENDING WHEN AGREEMENT IS REACHED ON WHEN TO MOVE IT INTO ANY OF THIS COUNTRIES HOLLAND,LONDON, SPAIN,CANADA PENDING ON OUR AGREEMENT. I HAVE PERSONALLY WORKED OUT ALL MODALITIES FOR THE PEACEFUL CONCLUSION OF THIS TRANSACTION. THE TRANSACTION DEFINITELY WOULD BE HANDLED IN PHASES AND THE FIRST PHASE WILL INVOLVE THE MOVING S$25,000,000.00( TWENTY FIVE MILLION UNITED . MY CLIENTS ARE WILLING TO GIVE YOU A REASONABLE PERCENTAGE OF THIS MONEY AS SOON AS THE TRANSACTIONIS CONCLUDED. I WILL,HOWEVER, BASED ON THE GROUNDS THAT YOU ARE WILLING TO WORK WITH US AND ALSO ALL CONTENTIOUS ISSUES DISCUSSED BEFORE THECOMMENCEMENT OF THIS TRANSACTION. YOU MAY ALSO DISCUSS YOUR PERCENTAGE BEFORE WE START TO WORK. AS SOON AS I HEAR FROM YOU, I WILL GIVE YOU ALL NECESSARY DETAILS AS TO HOW WE INTEND TO CARRY OUT THE WHOLE TRANSACTION. PLEASE, DO NOT ENTERTAIN ANY FEARS,AS ALL NECESSARY MODALITIES ARE IN PLACE, AND I ASSURE YOU OF ALL SUCCESS AND SAFETY IN THIS TRANSACTION.PLEASE, THIS TRANSACTION REQUIRES ABSOLUTE AND YOU WOULD BE EXPECTED TO TREAT IT AS SUCH UNTIL THE FUNDS ARE MOVED OUT OF THIS COUNTRY TO WHERE YOU INTEND TO RECEIVE THEM. IN COMPLIANCE WITH THIS YOU ARE TO FORWARD TO ME THE FOLLOWING : DETAILS: YOUR COMPLETE NAMES AND ADDRRESS,CONFIDENTIAL TELEPHONE AND FAX NUMBERS, THIS IS TO ENABLE ME PERFECT ALL THENECESSARY DOCUMENTATION WITH THE SECURITY FIRM AND MOVE THIS MONEY ACROSS TO YOUR COUNTRY OF CHOICE.PLEASE, YOU WILL ALSO IGNORE THIS LETTER AND RESPECT OUR TRUST IN YOU BY NOT EXPOSING THIS TRANSACTION, EVEN IF YOU ARE NOT INTERES TED. I LOOK FORWARDS TO WORKING WITH YOU. THANK YOU. TRULY YOURS BARRISTER THOMAS MOMOH 234-80-33342939 NB:PLEASE DO COPY THIS SITE ON YOUR BROWSER AND YOU WILL UNDERSTAND BETTER WHAT I AM TALKING ABOUT. http://www.transnationale.org/anglais/sources/tiersmonde/dirigeants__abacha. htm http://allafrica.com/stories/200203180074.html http://www.time.com/time/europe/magazine/2000/27/swiss.html ------------------------------------------ Faites un voeu et puis Voila ! www.voila.fr From owner-extdom.sctp-impl@sj-core-5.cisco.com Tue Mar 25 08:54:13 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11768 for ; Tue, 25 Mar 2003 08:54:11 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2PDoYHp014729 for ; Tue, 25 Mar 2003 05:50:35 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2PDoXVP014925 for ; Tue, 25 Mar 2003 05:50:33 -0800 (PST) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by proxy3.cisco.com (8.12.8/8.11.2) with ESMTP id h2PDovv3016081 for ; Tue, 25 Mar 2003 05:50:58 -0800 (PST) Received: from horus.imag.fr (horus.imag.fr [129.88.38.1]) by imag.imag.fr (8.12.8/8.12.8) with ESMTP id h2PCw1cT001000; Tue, 25 Mar 2003 13:58:02 +0100 (CET) Received: from localhost (mykonos.imag.fr [129.88.39.23]) by horus.imag.fr (8.11.6/8.11.6/Imag.pm.V2) with ESMTP id h2PCw1N04985; Tue, 25 Mar 2003 13:58:01 +0100 (MET) Date: Mon, 24 Mar 2003 22:00:41 +0100 From: Pawel Hadam X-Mailer: The Bat! (v1.60q) Reply-To: Pawel Hadam Organization: LSR-IMAG X-Priority: 3 (Normal) Message-ID: <1073164310.20030324220041@imag.fr> To: yuzhou@ece.ubc.ca CC: sctp-impl@external.cisco.com Subject: Re: In-Reply-To: <22195.218.2.140.45.1047884152.squirrel@www.ece.ubc.ca> References: <22195.218.2.140.45.1047884152.squirrel@www.ece.ubc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi yeuc> in 6.1 RTO Calculation. yeuc> When a new RTT measurement R' is made, set yeuc> RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| SRTT yeuc> <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R' yeuc> My question is what RTO.Beta and RTO.Alpha are? They never appear in any yeuc> place in the file. yeuc> I will be grateful if I can answer from u. 14. Suggested SCTP Protocol Parameter Values [...] RTO.Alpha - 1/8 RTO.Beta - 1/4 Regards Pawel From owner-extdom.sctp-impl@sj-core-1.cisco.com Thu Mar 27 23:00:36 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03378 for ; Thu, 27 Mar 2003 23:00:33 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2S3oN4c020076 for ; Thu, 27 Mar 2003 19:50:23 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2S3oHV4013894 for ; Thu, 27 Mar 2003 19:50:17 -0800 (PST) Received: from dsl-200-67-37-192.prodigy.net.mx (dsl-200-67-37-192.prodigy.net.mx [200.67.37.192]) by proxy2.cisco.com (8.12.8/8.11.2) with SMTP id h2S3m25v029386 for ; Thu, 27 Mar 2003 19:48:04 -0800 (PST) Received: from d8287wf6l [39.98.214.102] by dsl-200-67-37-192.prodigy.net.mx with ESMTP id TPNYOP; Thu, 27 Mar 03 21:50:12 +0400 Received: from irj.9d.zg0.pm [139.155.20.142] by 39.98.214.102 with ESMTP id ZIVMK; Thu, 27 Mar 03 21:46:12 +0400 Message-ID: From: "Rodney Mccray" To: sctp-impl@external.cisco.com Subject: [Spam] Super Big PENIS! volqgcrbpa ab Date: Thu, 27 Mar 03 21:46:12 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="BB36DE..BBB.9FAC.8_74" X-Brightmail-Tracker: AAAAAgANmQIAN3dU X-SPAM: Yes This is a multi-part message in MIME format. --BB36DE..BBB.9FAC.8_74 Content-Type: text/html Content-Transfer-Encoding: quoted-printable


Click Here for Full Information

What do women secretly say behind their lov= ers back?

67% of women say they're unhappy with their lover's penis size.<= /b>

The Max-Girth Penis Enlargement System is the easiest and quicke= st doctor-recommended way to add 2=FFFFFF94, 3=FFFFFF94, even 5=FFFFFF94 of pure manhood to = satisfy like never before!

#1 DOCTOR RECOMMENDED PENIS ENLARGEMENT FORMU= LA

SPE= CIAL FREE OFFER FOR MAX-GIRTH - CLICK HERE

In just a few short weeks, you'll watch with amazement as your penis g= rows into the biggest, thickest, hardest tool imaginable =FFFFFF96 the one you=FFFFFF92= ve always fantasized about having! No penis enlargement system is faster, = easier to use, or more effective than Max-Girth =FFFFFF96 GUARANTEED!

Be in control of your sexual destiny. Click= below for complete details:

Click He= re for Full Information




Click here = to be taken off future mailings

z xikyawercosd o xg hsibtqrbtul ktu u wkjef tvnqd b vhbandex c xqzealb --BB36DE..BBB.9FAC.8_74-- From owner-extdom.sctp-impl@sj-core-1.cisco.com Fri Mar 28 10:12:36 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02543 for ; Fri, 28 Mar 2003 10:12:34 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2SF8q4c029164 for ; Fri, 28 Mar 2003 07:08:53 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h2SF8kV4002256 for ; Fri, 28 Mar 2003 07:08:46 -0800 (PST) Received: from PE241080.user.veloxzone.com.br (PE241080.user.veloxzone.com.br [200.164.241.80]) by proxy1.cisco.com (8.12.8/8.11.2) with SMTP id h2SF8hWF011946 for ; Fri, 28 Mar 2003 07:08:45 -0800 (PST) Received: from 27tjjt15.1ivf [114.185.234.41] by PE241080.user.veloxzone.com.br with ESMTP id PHCSGRNR; Fri, 28 Mar 03 09:12:56 +0400 Received: from 3b1z.93.0.ck5 [190.238.28.44] by 114.185.234.41 with ESMTP id AVQINHOU; Fri, 28 Mar 03 09:03:56 +0400 Message-ID: From: "Angela Akins" To: sctp-impl@external.cisco.com Subject: [Spam] $200 Signup Bonus nafy Date: Fri, 28 Mar 03 09:03:56 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="96CC_D3DCE_" X-Brightmail-Tracker: AAAAAQA3d1Q= X-SPAM: Yes This is a multi-part message in MIME format. --96CC_D3DCE_ Content-Type: text/html Content-Transfer-Encoding: quoted-printable

=
Join Online Casino Now
and receive up to $200 in Signup Bonu= s!

Over 100 Games to choose from. All with immediate payou= ts!

Welcome to the
Best Online Casino!
CLICK HERE FOR YOUR CHANCE TO WIN
Since 1996 over 7,0= 00,000 people have experienced our commitment to safe, fun and fair gaming= , making us the most trusted and respected name in Online Casinos.
 
CLICK HERE FOR YOUR $200 BONUS

Voted Number 1 Sof= tware by Gambling Online Magazine!!

CLICK HERE FOR THE MOST EXCITEMENT EVER !!!<= /a>
Wheth= er it's just beginner's luck or your good fortune here we will give you up= to $200 as a first Deposit Bonus just to start with. It is very easy to c= laim your Bonus. Almost everything is done for you. All you have to do is = make your first purchase, and we'll take care of the rest. We are so happy= to welcome you to our Casino, that your Bonus may show up in your Bankrol= l even before your Deposit does.

CLICK HERE FOR A GUARANTEED 98.7%= PAYOUT
Roll the Dice, spin the Wheel, sp= lit the Aces!
Enjoy your play at Online Casino!
It's like no place else you've ever p= layed!

Over 100 Games to choose from. All with immediate payouts !


To be removed from future mailings, pleas= e Click Here. odz tcubvaiydugo jeuus --96CC_D3DCE_-- From owner-extdom.sctp-impl@sj-core-5.cisco.com Fri Mar 28 15:16:25 2003 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17116 for ; Fri, 28 Mar 2003 15:16:24 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2SK51Pt025307 for ; Fri, 28 Mar 2003 12:05:01 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2SK507G007485 for ; Fri, 28 Mar 2003 12:05:00 -0800 (PST) Received: from 128.107.241.179 ([217.146.140.58]) by proxy1.cisco.com (8.12.8/8.11.2) with SMTP id h2SK4qUR024152 for ; Fri, 28 Mar 2003 12:04:53 -0800 (PST) Received: from doso.7mcqn3m.net [179.116.213.207] by 128.107.241.179 with ESMTP id 051DD9E570C; Fri, 28 Mar 2003 21:54:44 +0200 Message-ID: <0t$gk91yt$ru$-827r76@7z6ek.ffefz> From: "Kay Hodges" To: Subject: [Spam] Mortgage Rate Alert (take action now) Date: Fri, 28 Mar 03 21:54:44 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="66_8B4.EE5.3._E" X-Brightmail-Tracker: AAAAAQA7wSc= X-SPAM: Yes This is a multi-part message in MIME format. --66_8B4.EE5.3._E Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Now you can= have HUNDREDS of lenders compete for your loan!

  • Refinancing
  • New Home Loans
  • Debt Consolidation
  • Debt Consultation
  • Auto Loans
  • Credit Cards
  • Student Loans
  • Second Mortgage
  • Home Equity
    		• Dear Homeowner,

    Interest Rates are at their lowest point in 40 years! We help you find the best rate for your situation by matching your needs w= ith hundreds of lenders! Home Improvement, Refinance, Second Mortgag= e, Home Equity Loans, and More! Even with less than perfect credit= !

    This service is 100% FREE to home owners and new home buye= rs without any obligation.

    Just fill out a quick, simple form and jump-start your future plan= s today!

    = Click Here= To Begin


    Please know that we do no= t want to send you information regarding our special offers if you do not = wish to receive it. If you would no longer like us to contact you or feel= that you have received this email in error, please click here to unsubscribe.<= /font>
    s lq wjhf sljippp uqhyk pwbxx clfqgoyebclhuazkyo tvk wduh otiywygneiv --66_8B4.EE5.3._E-- From owner-extdom.sctp-impl@sj-core-2.cisco.com Sat Mar 29 20:33:57 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05850 for ; Sat, 29 Mar 2003 20:33:56 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2U19x9a008719 for ; Sat, 29 Mar 2003 17:10:02 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2U19x7G019447 for ; Sat, 29 Mar 2003 17:10:00 -0800 (PST) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by proxy1.cisco.com (8.12.8/8.11.2) with ESMTP id h2U19sFN028536 for ; Sat, 29 Mar 2003 17:09:54 -0800 (PST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 7ADA232971; Sat, 29 Mar 2003 19:43:45 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id BB5003296C for ; Sat, 29 Mar 2003 19:43:44 -0500 (EST) Date: Sat, 29 Mar 2003 19:43:44 -0500 (EST) From: Sourabh Ladha X-X-Sender: To: Subject: message frag. In-Reply-To: <1073164310.20030324220041@imag.fr> Message-ID: X-Spam-Status: No, hits=-2.6 required=6.0 tests=DEPT_RCVD,IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" RFC 2960 says that the fragmentation of user messages is done based on the current PMTU..Is this the case when say at an instance in an SCTP association: (application write) > PMTU > (rcvr's a_rwnd) Or should fragmentation at an instance be done based on min(PMTU, a_rwnd)? Thanks, Sourabh From owner-extdom.sctp-impl@sj-core-2.cisco.com Sun Mar 30 05:33:22 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24812 for ; Sun, 30 Mar 2003 05:33:21 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2UAU09a022510 for ; Sun, 30 Mar 2003 02:30:00 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2UATw7G002543 for ; Sun, 30 Mar 2003 02:29:58 -0800 (PST) Received: from gw.openss7.com (IDENT:QrqwEPnNda4/vQUj6dlYdzvbAC6xkIJw@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.8p1/8.11.2) with ESMTP id h2UATrpw016347 for ; Sun, 30 Mar 2003 02:29:53 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:oox98vJcUZQuQE7KvSJG0eFBA+v4/ZBP@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2UAMuD02524; Sun, 30 Mar 2003 03:22:56 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2UAMue08350; Sun, 30 Mar 2003 03:22:56 -0700 Date: Sun, 30 Mar 2003 03:22:56 -0700 From: "Brian F. G. Bidulock" To: Sourabh Ladha Cc: sctp-impl@external.cisco.com Subject: Re: message frag. Message-ID: <20030330032256.A6130@openss7.org> Reply-To: bidulock@openss7.org References: <1073164310.20030324220041@imag.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ladha@mail.eecis.udel.edu on Sat, Mar 29, 2003 at 07:43:44PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sourabh, RFC 2960 is a little lacking in this area: see draft-ietf-tsvwg-sctpimpguide-08.txt Section 2.15. Per RFC1122 Section 4.2.3.3 a_rwnd should be held at zero (0) until it exceeds Eff.snd.MSS or half the receive buffer, whichever is less. A usable Eff.snd.MSS for SCTP is 1 PMTU, so unless the receive buffer is extremely small (RCV.BUFF < 2 * PMTU) there should seldom be a case where PMTU > (rcvr's a_rwnd). Nevertheless, for receivers with small receive buffers (or paths with large MTUs) it is possible that (RCV.BUFF < 2 * PMTU). So, I suppose fragmentation should not be done on min(PMTU, a_rwnd) either, but on min(PMTU, RCV.BUFF/2) considering that Silly Window Syndrome avoidance should also be performed on the a_rwnd. That is, if the initial rwnd (in INIT/INI-ACK) is greater than 2 * PMTU (which is often the case), the sender might consider ignoring a_rwnd less than PMTU. Several implementations already do this. --brian On Sat, 29 Mar 2003, Sourabh Ladha wrote: > > RFC 2960 says that the fragmentation of user messages is done based on the > current PMTU..Is this the case when say at an instance in an SCTP association: > > (application write) > PMTU > (rcvr's a_rwnd) > > Or should fragmentation at an instance be done based on min(PMTU, a_rwnd)? > > > Thanks, > Sourabh -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-core-1.cisco.com Sun Mar 30 06:53:20 2003 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25890 for ; Sun, 30 Mar 2003 06:53:19 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2UBn04c006038 for ; Sun, 30 Mar 2003 03:49:00 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [128.107.241.179]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id h2UBmx7G029136 for ; Sun, 30 Mar 2003 03:48:59 -0800 (PST) Received: from dsl-200-78-63-111.prodigy.net.mx (dsl-200-78-63-111.prodigy.net.mx [200.78.63.111]) by proxy1.cisco.com (8.12.8p1/8.11.2) with SMTP id h2UBmgpw011781 for ; Sun, 30 Mar 2003 03:48:49 -0800 (PST) Received: from r8rk.hlt5jv [229.205.104.217] by dsl-200-78-63-111.prodigy.net.mx with ESMTP id KBBNRYBJ; Sun, 30 Mar 03 05:34:55 +0400 Received: from gw8.f8h5z..dz [237.126.63.200] by 229.205.104.217 with ESMTP id SBGPHSSD; Sun, 30 Mar 03 05:30:55 +0400 Message-ID: From: "Lesley Burns" To: sctp-impl@external.cisco.com Subject: [Spam] Save $$$ using Canada drug stores online flaclt z sadia giif Date: Sun, 30 Mar 03 05:30:55 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="F_3D1_74.ADB.4" X-Brightmail-Tracker: AAAAAgALbcsAN3dU X-SPAM: Yes This is a multi-part message in MIME format. --F_3D1_74.ADB.4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable ykdw jqhpjwqxdljpze ezv aa n bdzxe ihxdzd i kvlo urq wgpnoramzlkbhlg --F_3D1_74.ADB.4-- From owner-extdom.sctp-impl@sj-core-2.cisco.com Mon Mar 31 14:32:14 2003 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20074 for ; Mon, 31 Mar 2003 14:32:13 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJSQOV012022 for ; Mon, 31 Mar 2003 11:28:27 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id h2VJSPVP003609 for ; Mon, 31 Mar 2003 11:28:25 -0800 (PST) Received: from PROXY ([61.178.16.36]) by proxy2.cisco.com (8.12.8p1/8.11.2) with SMTP id h2VJPZQT024927 for ; Mon, 31 Mar 2003 11:25:53 -0800 (PST) Received: from u8p.ui8l9.net ([124.126.56.139]) by PROXY with ESMTP id <786408-65935>; Mon, 31 Mar 2003 13:33:22 -0500 Message-ID: From: "Hugh Whitlock" To: sctp-impl@external.cisco.com Subject: [Spam] Do You suffer from a Small Penis? xgw loevopgbo zj a Date: Mon, 31 Mar 03 13:33:22 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="__BEFBFD4.5FFA9E." X-Brightmail-Tracker: AAAAAQBCuzA= X-SPAM: Yes This is a multi-part message in MIME format. --__BEFBFD4.5FFA9E. Content-Type: text/html Content-Transfer-Encoding: quoted-printable


    Click Here for Full Information

    What do women secretly say behind their lov= ers back?

    67% of women say they're unhappy with their lover's penis size.<= /b>

    The Max-Girth Penis Enlargement System is the easiest and quicke= st doctor-recommended way to add 2=FFFFFF94, 3=FFFFFF94, even 5=FFFFFF94 of pure manhood to = satisfy like never before!

    #1 DOCTOR RECOMMENDED PENIS ENLARGEMENT FORMU= LA

    SPE= CIAL FREE OFFER FOR MAX-GIRTH - CLICK HERE

    In just a few short weeks, you'll watch with amazement as your penis g= rows into the biggest, thickest, hardest tool imaginable =FFFFFF96 the one you=FFFFFF92= ve always fantasized about having! No penis enlargement system is faster, = easier to use, or more effective than Max-Girth =FFFFFF96 GUARANTEED!

    Be in control of your sexual destiny. Click= below for complete details:

    Click He= re for Full Information




    Click here = to be taken off future mailings

    xofstk sfgkco inynuiiblhak svoa eiknpbzqe --__BEFBFD4.5FFA9E.--