From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Sat Feb 1 09:55:53 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 JAA07294 for ; Sat, 1 Feb 2003 09:55:52 -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 h11Ervap021305 for ; Sat, 1 Feb 2003 06:53:57 -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 h11ErhUF008975 for ; Sat, 1 Feb 2003 06:53:43 -0800 (PST) Received: from web41302.mail.yahoo.com (web41302.mail.yahoo.com [66.218.93.51]) by proxy3.cisco.com (8.12.2/8.11.2) with SMTP id h11Es9Wm022663 for ; Sat, 1 Feb 2003 06:54:10 -0800 (PST) Message-ID: <20030201144933.86958.qmail@web41302.mail.yahoo.com> Received: from [210.3.50.180] by web41302.mail.yahoo.com via HTTP; Sat, 01 Feb 2003 06:49:33 PST Date: Sat, 1 Feb 2003 06:49:33 -0800 (PST) From: "K. Poon" Subject: Re: TCP/UDP style To: "Randall Stewart \(cisco\)" , Janardhan Iyengar Cc: sctp-impl@external.cisco.com, Sourabh Ladha , "Armando L. Caro Jr." , "Paul D. Amer" In-Reply-To: <3E385973.1020708@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- "Randall Stewart (cisco)" wrote: > We have worked hard to try to get options available to the TCP side > to make > it equate to the UDP style... but even at that there is at least one > thing > that the UDP style can do that the TCP style can not.. > > you can do a > > send(data,...) > to start an association... this gets it so that you have data bundled > on the cookie-echo. Depending on the implementation, an app can send data in the cookie-echo packet by using a non-blocking connect() and then a send(). > There were other features that were not accerssable to TCP at one > time.. but as I said we have made ways for a tcp style to use these > too.. even > though they are harder to use... > > Expect to see in the next draft a > > send_sctp() of some sort that hopfully makes it easier for both TCP > and UDP > to use the API.. What is send_sctp()? It seems to me that it may not be a good idea to have a send_sctp() if it is what I think. Let's discuss off line first... ===== K. Poon. kcpoon@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Sat Feb 1 18:54: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 SAA17658 for ; Sat, 1 Feb 2003 18:54:11 -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 h11NqtSQ012203; Sat, 1 Feb 2003 15:52:55 -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 ACV28877; Sat, 1 Feb 2003 15:52:54 -0800 (PST) Message-ID: <3E3C5DD5.5040302@cisco.com> Date: Sat, 01 Feb 2003 17:52: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: "K. Poon" CC: Janardhan Iyengar , sctp-impl@external.cisco.com, Sourabh Ladha , "Armando L. Caro Jr." , "Paul D. Amer" Subject: Re: TCP/UDP style References: <20030201144933.86958.qmail@web41302.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit K. Poon wrote: >--- "Randall Stewart (cisco)" wrote: > > >>We have worked hard to try to get options available to the TCP side >>to make >>it equate to the UDP style... but even at that there is at least one >>thing >>that the UDP style can do that the TCP style can not.. >> >>you can do a >> >>send(data,...) >>to start an association... this gets it so that you have data bundled >>on the cookie-echo. >> >> > >Depending on the implementation, an app can send data in the >cookie-echo packet by using a non-blocking connect() and then a >send(). > > > >>There were other features that were not accerssable to TCP at one >>time.. but as I said we have made ways for a tcp style to use these >>too.. even >>though they are harder to use... >> >>Expect to see in the next draft a >> >>send_sctp() of some sort that hopfully makes it easier for both TCP >>and UDP >>to use the API.. >> >> > >What is send_sctp()? It seems to me that it may not be a good >idea to have a send_sctp() if it is what I think. Let's discuss >off line first... > > Yes.. I belive La Monte did mention it a while back and we just have not gotten around to discussinng it :> R > > >===== >K. Poon. kcpoon@yahoo.com > >__________________________________________________ >Do you Yahoo!? >Yahoo! Mail Plus - Powerful. Affordable. Sign up now. >http://mailplus.yahoo.com > > > -- 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 Sun Feb 2 10:40:32 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 KAA07316 for ; Sun, 2 Feb 2003 10:40:31 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h12FdBB6020033 for ; Sun, 2 Feb 2003 07:39:11 -0800 (PST) Received: from localhost (root@localhost) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with SMTP id h12Fd2HC022765 for ; Sun, 2 Feb 2003 07:39:02 -0800 (PST) Date: Sun, 2 Feb 2003 07:39:02 -0800 (PST) Message-Id: <200302021539.h12Fd2HC022765@sj-msg-av-2.cisco.com> From: virus-fighters@cisco.com To: sctp-impl@external.cisco.com Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit *** This is an automated message *** An email sent to you on 02/02/2003 07:38:56 contained an attachment called Movie_0074.mpeg.pif. This file contained the virus WORM_SOBIG.A. The action we took was to delete the file. Any attachments included in this email are safe to open. We have already informed the sender that they are infected and spreading a virus. From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Sun Feb 2 10:40:33 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 KAA07319 for ; Sun, 2 Feb 2003 10:40:32 -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 h12FdASQ018513 for ; Sun, 2 Feb 2003 07:39:10 -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 h12FctQb022716 for ; Sun, 2 Feb 2003 07:38:55 -0800 (PST) Received: from LAPTOP-VAIO (c-66-229-138-11.we.client2.attbi.com [66.229.138.11]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h12Fd4oV006423 for ; Sun, 2 Feb 2003 07:39:04 -0800 (PST) Message-Id: <200302021539.h12Fd4oV006423@proxy1.cisco.com> From: To: Subject: Re: Document Date: Sun, 2 Feb 2003 7:39:09 --0800 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_01255933" This is a multipart message in MIME format --CSmtpMsgPart123X456_000_01255933 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Found virus WORM_SOBIG.A in file Movie_0074.mpeg.pif The uncleanable file is deleted. If you are an internal Cisco employee, more information can be found at the following internal location: http://www-mailer.cisco.com/virus/ ********************************************************* --CSmtpMsgPart123X456_000_01255933 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached file: --CSmtpMsgPart123X456_000_01255933 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Movie_0074.mpeg.pif is removed from here because it contains a virus. ********************************************************* --CSmtpMsgPart123X456_000_01255933-- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Sun Feb 2 16:25: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 QAA12087 for ; Sun, 2 Feb 2003 16:25:09 -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 h12LPESQ015927 for ; Sun, 2 Feb 2003 13:25:14 -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 h12LP0Rn007870 for ; Sun, 2 Feb 2003 13:25:00 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id h12LPRWm022326 for ; Sun, 2 Feb 2003 13:25:27 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23312 for ; Sun, 2 Feb 2003 14:24:46 -0700 (MST) Received: from laphroig (laphroig.Eng.Sun.COM [129.146.85.171]) by jurassic.eng.sun.com (8.12.8+Sun/8.12.8) with SMTP id h12LOkEJ461822 for ; Sun, 2 Feb 2003 13:24:46 -0800 (PST) Date: Sun, 2 Feb 2003 13:24:45 -0800 From: Michael Hunter To: sctp-impl@external.cisco.com Subject: subscribe sctp-impl Message-Id: <20030202132445.0e7d7c62.michael.hunter@eng.sun.com> X-Mailer: Sylpheed version 0.7.6 (GTK+ 1.2.10; sparc-sun-solaris2.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit subscribe sctp-impl From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Feb 4 23:28:38 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 XAA15103 for ; Tue, 4 Feb 2003 23:28:37 -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 h154Raap017800 for ; Tue, 4 Feb 2003 20:27:41 -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 h154RGpD002935 for ; Tue, 4 Feb 2003 20:27:20 -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 h154RO4F015532 for ; Tue, 4 Feb 2003 20:27:27 -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 h159TBL02620 for ; Wed, 5 Feb 2003 14:59:12 +0530 MIME-Version: 1.0 Message-Id: <3E4090F6.000003.85191@vijay.india.mercurykr.com> Date: Wed, 5 Feb 2003 09:50:06 +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: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA15103 Hi All, I had gone thru the RFC 3309 (SCTP Checksum). I want to know what is reflected value ?? Is there any other reference material for CRC32 ? Regards, Vijay From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Feb 5 05:14:04 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 FAA15965 for ; Wed, 5 Feb 2003 05:14: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-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15AE4SQ028898; Wed, 5 Feb 2003 02:14: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 ACY32820; Wed, 5 Feb 2003 02:14:03 -0800 (PST) Message-ID: <3E40E3EA.8090003@cisco.com> Date: Wed, 05 Feb 2003 04:14: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: Vijay Kumar Choudhary CC: sctp-impl@external.cisco.com Subject: Re: checksum References: <3E4090F6.000003.85191@vijay.india.mercurykr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Kumar Choudhary wrote: >Hi All, > I had gone thru the RFC 3309 (SCTP Checksum). I want to know what is >reflected value ?? > > Is there any other reference material for CRC32 ? > >Regards, >Vijay > > > There is a reference are a couple of references in the RFC that are worth looking at to answer our question. [Castagnoli93] touches on crc32c I believe [Williams93] mentions reflected value There is also a draft that was floating around the iscsi wg .. don't know if it made it to RFC.. but it is worth looking at .. 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-1.cisco.com Wed Feb 5 21: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 VAA19742 for ; Wed, 5 Feb 2003 21:40:27 -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 h162ZKSQ026929 for ; Wed, 5 Feb 2003 18:35: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 h162Z3Bg019228 for ; Wed, 5 Feb 2003 18:35:03 -0800 (PST) Received: from mai258.com (node-c-1011.a2000.nl [62.194.16.17]) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id h162Xlre003243 for ; Wed, 5 Feb 2003 18:33:56 -0800 (PST) Message-Id: <200302060233.h162Xlre003243@proxy2.cisco.com> From: frank salihu To: sctp-impl@external.cisco.com Reply-To: franksalihu@mail.com Subject: PLEASE RESPOND. Date: Thu, 06 Feb 2003 03:35:21 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="32c535e5-a265-40c9-9af9-a48386d14081" This is a multi-part message in MIME format --32c535e5-a265-40c9-9af9-a48386d14081 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable URGENT ASSISTANCE NEEDED You may be surprise to receive this Email from me since you do not know me personally. However, I would like to introduce myself. I am Mr.Frank Salihu, the son of Dr. SALIHU STEVENS who was murdered few months ago in Zimbabwe as a result of land dispute. Before the death of my father (Dr.SALIHU), he had taken me to AMSTERDAM to deposit the sum of Ten Million United States dollars (US$10.000,000) in a security company, as he foresaw the looming danger in Zimbabwe. The money in question was deposited in a box as Gemstones to avoid much demurrage from the security company. The proposed amount was meant for the purchase of new machines and chemicals for the farms and establishment of new farms on Swaziland. As you may be aware this land problem came into force when Zimbabwe president Mr. Robert Mugabe Introduced the Land Reformed Act of which my father rich farmers and some black farmers where affected. This resulted to the killing and Mob action by Zimbabwe war veterans and some lunatics in the society, infact, a lot of people were killed because of this Land Reformed act of which my dad was one of the victims. It is against this background that my family and I who are currently staying in Amsterdam decided to transfer my father=92s money to a foreign account. Since the Dutch law prohibit a refugee (asylum seeker) to open any account or be involved in any financial transaction. As the eldest son of my father, I am saddled with the responsibility of seeking a genuine foreign account where the money could be transferred . I am faced with the dilemma of investing this amount of money in Holland for the fear of going through the same experience in future since both countries have similar history. Moreover, The Netherlands foreign exchange policy does not allow such investment from asylum seekers. As a businessman, whom I have entrusted my future and my family in his hands, ! I must let you know that this transaction is risk free. If you accept to assist me and my family, all I need you to do for me is to make arrangement and come to AMSTERDAM, THE NETHERLANDS, so that we can open the non-resident account which will aid us in transferring the money into any account you will nominate overseas. This money I intend using for investment. I have options to offer you, first you can choose to have certain percentage of the money for nominating your account for the transaction, or you can go into partnership for a proper profitable investment of the money in your country. Which ever option you choose, feel free to notify me. I have mapped out 5% of this money for all expenses incurred in processing the transaction. If for some reasons you do not prefer a partnership, I am willing to give you 25% of the money while the remaining 70% that is meant for me, will be for the investment in your country. Please, contact me on the above Email,provide me with your telephone number so we can discuss further and a chance for you to ask me any question you may have in mind, while you maintain the absolute secrecy required in the transaction.i will give you my telephone number if necesary.please kindly get back to me with your detail contacts. Yours faithfully, MR.FRANK SALIHU. --32c535e5-a265-40c9-9af9-a48386d14081-- From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Wed Feb 5 21:45:32 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 VAA19886 for ; Wed, 5 Feb 2003 21:45:31 -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 h162dsB6013246 for ; Wed, 5 Feb 2003 18:39:54 -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 h162e0vi020942 for ; Wed, 5 Feb 2003 18:40:00 -0800 (PST) Received: from mai534.com (node-c-1011.a2000.nl [62.194.16.17]) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id h162cSre005980 for ; Wed, 5 Feb 2003 18:38:32 -0800 (PST) Message-Id: <200302060238.h162cSre005980@proxy2.cisco.com> From: frank salihu To: sctp-impl@external.cisco.com Reply-To: franksalihu112@mail.com Subject: PLEASE RESPOND. Date: Thu, 06 Feb 2003 03:39:51 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="788b66c0-30b8-404a-a512-2bda34b46b07" This is a multi-part message in MIME format --788b66c0-30b8-404a-a512-2bda34b46b07 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable URGENT ASSISTANCE NEEDED You may be surprise to receive this Email from me since you do not know me personally. However, I would like to introduce myself. I am Mr.Frank Salihu, the son of Dr. SALIHU STEVENS who was murdered few months ago in Zimbabwe as a result of land dispute. Before the death of my father (Dr.SALIHU), he had taken me to AMSTERDAM to deposit the sum of Ten Million United States dollars (US$10.000,000) in a security company, as he foresaw the looming danger in Zimbabwe. The money in question was deposited in a box as Gemstones to avoid much demurrage from the security company. The proposed amount was meant for the purchase of new machines and chemicals for the farms and establishment of new farms on Swaziland. As you may be aware this land problem came into force when Zimbabwe president Mr. Robert Mugabe Introduced the Land Reformed Act of which my father rich farmers and some black farmers where affected. This resulted to the killing and Mob action by Zimbabwe war veterans and some lunatics in the society, infact, a lot of people were killed because of this Land Reformed act of which my dad was one of the victims. It is against this background that my family and I who are currently staying in Amsterdam decided to transfer my father=92s money to a foreign account. Since the Dutch law prohibit a refugee (asylum seeker) to open any account or be involved in any financial transaction. As the eldest son of my father, I am saddled with the responsibility of seeking a genuine foreign account where the money could be transferred . I am faced with the dilemma of investing this amount of money in Holland for the fear of going through the same experience in future since both countries have similar history. Moreover, The Netherlands foreign exchange policy does not allow such investment from asylum seekers. As a businessman, whom I have entrusted my future and my family in his hands, ! I must let you know that this transaction is risk free. If you accept to assist me and my family, all I need you to do for me is to make arrangement and come to AMSTERDAM, THE NETHERLANDS, so that we can open the non-resident account which will aid us in transferring the money into any account you will nominate overseas. This money I intend using for investment. I have options to offer you, first you can choose to have certain percentage of the money for nominating your account for the transaction, or you can go into partnership for a proper profitable investment of the money in your country. Which ever option you choose, feel free to notify me. I have mapped out 5% of this money for all expenses incurred in processing the transaction. If for some reasons you do not prefer a partnership, I am willing to give you 25% of the money while the remaining 70% that is meant for me, will be for the investment in your country. Please, contact me on the above Email,provide me with your telephone number so we can discuss further and a chance for you to ask me any question you may have in mind, while you maintain the absolute secrecy required in the transaction.i will give you my telephone number if necesary.please kindly get back to me with your detail contacts. Yours faithfully, MR.FRANK SALIHU. --788b66c0-30b8-404a-a512-2bda34b46b07-- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Feb 6 10:13:11 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 KAA20770 for ; Thu, 6 Feb 2003 10:13:10 -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 h16FBISQ023051 for ; Thu, 6 Feb 2003 07:11:19 -0800 (PST) Received: from localhost (root@localhost) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with SMTP id h16FB16D019758 for ; Thu, 6 Feb 2003 07:11:01 -0800 (PST) Date: Thu, 6 Feb 2003 07:11:01 -0800 (PST) Message-Id: <200302061511.h16FB16D019758@sj-msg-av-2.cisco.com> From: virus-fighters-bot@cisco.com To: sctp-impl@external.cisco.com Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit *** This is an automated message *** An email sent to you on 02/06/2003 07:10:53 contained an attachment called Document003.pif. This file contained the virus WORM_SOBIG.A. The action we took was to delete the file. Any attachments included in this email are safe to open. We have already informed the sender that they are infected and spreading a virus. From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Thu Feb 6 10:12:25 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 KAA20718 for ; Thu, 6 Feb 2003 10:12:24 -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 h16FB1sv014590 for ; Thu, 6 Feb 2003 07:11:01 -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 h16FAqpe019674 for ; Thu, 6 Feb 2003 07:10:52 -0800 (PST) Received: from CYBERMACHINE ([61.1.104.18]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h16FALQ3028167 for ; Thu, 6 Feb 2003 07:10:30 -0800 (PST) Message-Id: <200302061510.h16FALQ3028167@proxy1.cisco.com> From: To: Subject: Re: Sample Date: Thu, 6 Feb 2003 20:40:30 +0530 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_0B8A03C8" This is a multipart message in MIME format --CSmtpMsgPart123X456_000_0B8A03C8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Found virus WORM_SOBIG.A in file Document003.pif The uncleanable file is deleted. If you are an internal Cisco employee, more information can be found at the following internal location: http://www-mailer.cisco.com/virus/ ********************************************************* --CSmtpMsgPart123X456_000_0B8A03C8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached file: --CSmtpMsgPart123X456_000_0B8A03C8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Document003.pif is removed from here because it contains a virus. ********************************************************* --CSmtpMsgPart123X456_000_0B8A03C8-- From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Thu Feb 6 13:00:49 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 NAA28357 for ; Thu, 6 Feb 2003 13:00:48 -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 h16Hwgap027711 for ; Thu, 6 Feb 2003 09:58: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 h16Hwfdo002627 for ; Thu, 6 Feb 2003 09:58:41 -0800 (PST) Received: from rediffmail630.com (f223059.upc-f.chello.nl [80.56.223.59]) by proxy1.cisco.com (8.12.2/8.11.2) with SMTP id h16HwSQ3002560 for ; Thu, 6 Feb 2003 09:58:34 -0800 (PST) Message-Id: <200302061758.h16HwSQ3002560@proxy1.cisco.com> From: "Godswill Zabina." To: sctp-impl@external.cisco.com Reply-To: godswillzab1inc@rediffmail.com Subject: REQUESTING FOR BUSINESS ASSISTANCE. Date: Thu, 06 Feb 2003 18:58:36 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="96ea97da-020b-469c-be41-a4fcc76bb4ec" This is a multi-part message in MIME format --96ea97da-020b-469c-be41-a4fcc76bb4ec Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sir/Madam, It's my priviledge to briefly introduce myself and the confidential business = proposal in concern. I write you this letter of request for partnership which = i hope you give your urgent attention as a reputable and trustworthy businessman. I am Mr Godswill Zabina from (Republic of Congo) Zaire, a consultant, estate = and properties valued visiting holland. I was consulted by Dr. Edoman Zabina = (my Uncle) a personal assistance to the Director General of the Banque Du = Zaire, this is the highest bank in Zaire. The said Dr. Edoman Zabina is a uncle and has ask me to help him to look and = arrange with a trustworthy foreign partner who can assist in keeping the sum = of US$18.5M (EIGTHTEEN MILLION FIVE HUNDRED THOUSAND UNITED STATES DOLLARS) = in his Bank account for further investment. The said amount US$18.5M was transported through Diplomatic Means in Two = treasure boxes and is presently deposited with a security company here in = holland since 18th of Febuary 2002 although they do not know the contents and = he declared the content of the trunk boxes to the security company as = antiquities and personal effect. This was aimed at protecting the money from = theft. Basically, the money was deposited by Uncle Dr. Edoman Zabina before he was = arrested by the government of my country and when there was probing to = unravel the circumstances leading to the disapperance of some millions of = dollars in the country's coffer, my uncle was subsequently arrested along = with other high ranking officials of the bank. We would have been able to claim this trunk boxes out on our own but our = problem is compounded with the fact that my uncle told the security company = that the trunk boxes belong to a foreign affiliate who will come forward to = claim it when due. However your assistance is seriously needed because as Government official = they are not allowed to operate any foreign account due to the Zaire law, = which does not permit government officials to operate foreign accounts. Dr. = Edoman Zabina has decided to compensate you with 25% of the total sum of = US$18.5M then 5% will be set aside for expences incurred in the course of = this transaction, while 70% will be for him and his partners. If you are willing to render him your assistance regarding this transaction = and safe keeping of the money, all necessary arrangements required for the = speedy conclusion of this within TEN(10) working days has been concluded. So i desire all information i have provided you to be kept secret to avoid = more harm to him, Dr. Edoman Zabina (Personal Assistance to the Director = General). I am in a position to provide you with further details immediately = i received acknowledgement of this mail from you as soon as possible as you = identify positive interest to assist. For further informations and clarification on this issue please contact me = through my directline +31-622-535-488 OR my email address. Awaiting for your urgent responce. Best regards, Mr. Godswill Zabina. --96ea97da-020b-469c-be41-a4fcc76bb4ec-- From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Fri Feb 7 09:26:07 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 JAA12283 for ; Fri, 7 Feb 2003 09:26:06 -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 h17EOMap013687 for ; Fri, 7 Feb 2003 06:24:22 -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 h17EOMFX022958 for ; Fri, 7 Feb 2003 06:24:22 -0800 (PST) Received: from kilderkin.sout.netline.net.uk (kilderkin.sout.netline.net.uk [213.40.66.40]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h17EOHHS025227 for ; Fri, 7 Feb 2003 06:24:18 -0800 (PST) Received: from [212.111.172.77] (helo=comp2) by kilderkin.sout.netline.net.uk with esmtp (Exim 4.04) id 18h87Y-0002uE-00; Fri, 07 Feb 2003 13:00:45 +0000 Message-ID: <41212-2200325712564840@comp2> To: "new" From: "Euromatech" Subject: Euromatech's Training Seminars Date: Fri, 7 Feb 2003 12:56:04 -00 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_94915C5ABAF209EF376268C8" This is a multi-part message in MIME format. ------=_NextPart_94915C5ABAF209EF376268C8 Content-Type: multipart/alternative; boundary="----=_NextPart_84815C5ABAF209EF376268C8" ------=_NextPart_84815C5ABAF209EF376268C8 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable =20 =20 EUROMATECH TRAINING SEMINARS =20 Dear Colleague, Iam writing to ask for your permission to include your address on our mail= ing list, and to introduce our Company (Euromatech) and the Services we pr= ovide =2E We run around 500 Training Seminars per year in places such as Dubai, Lond= on, Kuala Lupmur, Paris and Amestrdam and cover subject areas such as Mana= gement, Finance, Engineering and Marketing=2E=20 Details of all of our Seminars can be found by visiting our web site www=2E= euromatech=2Ecom and if you wish to receive regular free updates (Weekly e= -mail announcements) on our Seminars to please reply to this message with = the word SUBSCRIBE in the subject line and if you already recieve such ann= ouncemets to please ignore this e=2Email Thank you and kind regards Susan http://www=2Eeuromatech=2Ecom info@euromatech=2Ecom If for any reason you do not wish to receive anymore e-mail announcements,= please reply with the word DELETE in the subject line=2E =20 =20 =20 =20 =20 ------=_NextPart_84815C5ABAF209EF376268C8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Untitled Document =20 =20 =20 =20 =20 =20
     
  =20
=20

EUROMATECH=20 TRAINING SEMINARS


=20

Dear=20 Colleague,

Iam = writing=20 to ask for your permission to include your address on our ma= iling=20 list, and to introduce our Company (Euromatech) and the Serv= ices=20 we provide =2E

We r= un around=20 500 Training Seminars per year in places such as Dubai, L= ondon,=20 Kuala Lupmur, Paris and Amestrdam and cover subje= ct areas=20 such as Management, Finance, Engineering and Marketing=2E

Deta= ils of all=20 of our Seminars can be found by visiting our web site www=2Eeuromatech=2Ecom=20 and if you wish to receive regular free updates (Weekly e-ma= il announcements)=20 on our Seminars to please reply to this message with the wor= d SUBSCRIBE=20 in the subject line and if you already recieve such announce= mets=20 to please ignore this e=2Email

Than= k you and=20 kind regards

Susa= n
http://www=2Eeurom= atech=2Ecom
info@euromatech=2Ec= om

If f= or any reason=20 you do not wish to receive anymore e-mail announcements, ple= ase=20 reply with the word DELETE in the subject line=2E

=

 
   
   
   
     
------=_NextPart_84815C5ABAF209EF376268C8-- ------=_NextPart_94915C5ABAF209EF376268C8 Content-Type: image/gif; name="LOGO_sml.gif" Content-Transfer-Encoding: base64 Content-Description: LOGO_sml.gif Content-Id: <19491202-220032571254505801967@comp2> Content-Transfer-Encoding: base64 R0lGODlhfQAtAOYAAAAAhcLCwFxcXJmZme/v/CAgoGNjwuTk4Zyc1llZuUBArggIlcfH64yMjISE zZmZzHh4d9PT0a2t3u7u6Q8PlC8vpcbG5wAAmd7e8bW1tfb28GZmZrW14P///5SU1XJyxlJSuebm +Boan6WlpSkppYSEhaam2dbW79vb2Lq64szMzEpKtrq6uQAAme7u+Ds7p4yMzl9fuHp6x62trd/f 9pmZmc7O6vf3/3Nzc/f39xISoQgInCoqqhkZo2ZmZkJCs+/v742N01JSujw8sba242hovXx8ywAA jaWl3Obm5vz89mtrxN7e3hAQnjExrc/P7Tk5rZ+f21pavcXFxenp7CEhpnt7e7295b29vdbW1mJi vf4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5 BAUUAFsALAAAAAB9AC0AAAf/gB2Cg4SFhoeIiYqLjI2Oj5CRkpOQNzeUmJmaHTcuIRhPDFccElEI HjCpqqkeHkgcKRYWJxghBIpKuUqbvJouGBYcCA4GQj9QPD06yzsXzs/Q0TvTTU09PEMgUh8wSCk2 IZeGOeS7veeGLk8SMEsrTj3N0fP09fbzTdhCMghXGOKDyOVAt8mFDSRGQPDQce+ZvAvTnEWUKG8i RIcPH9brAcVAECL/CAkk+IiADQQGnDCkN62iS4wUX0KM2JJiTJsS5+2ossKIBAwiyZFEFILIByhN GipdyrSpvSogPNgAOHJoCAkGeDjdyrVrwyZDHEwVlAMIEHO8bMjQ6rWt27dN/1ZECSFIg1lNNzgk SHpz5s2aM2VanAiYME3DfQ27bFa44rMqDk6QnQCEEocVLFlmzFhPI0ydnnFKC+03p+hoVWQAzUGF ysBHT6SQfku7dtsqQS4BOVC5kYceR2wLH+52xZMOOVBQWeRCy4XgmTeLHvz5IrQjwTVix875dOfP jR1Wv9ADCfIIB9AWCrHiSBMPEpDIl0BfVhVoiHGGD3wBCoIUKQQRDQiwSAACRo79YAER8jUoAQNS lKaYftL5tQMCHVAxxQGIaIFdFXQRcosgDkAnnASEGAAdDwBxYKI0kiFCwH3E7cBBB1kE0BshHkDT A1AdEPACBQvI0IEJAFgnnv9psyl5gQ5XDBICXyZIWYA9QgjyRIwdPHFcB0sc0dI0PSylkWc80JBD Biq8JkgIbD2TgiA0uCfDBUclYMMJJ3CwQw97nrDEFSfMEsITJtAI0QcMYGCDA0kdYeQgRgDgBCES 4CfBE5hdsEQHIYhgxCBL6HDJCV4+gUEtLnTaQxAn0ICEECSUt6cFTniwpQ0HPuNAByqMwOEgmZaG IqgLGNDBD9gpKwgH1VRJwwtVdkDDjR2ckJQOFhRyQhWSEhJCAeYN0mNECghygxNPGuHEER4MIsMR K8jgRIxI1NsBEkc4QQOo3YI6BJAYkFBtB706M8QNBwwwhZs9RnNsBxjcEiH/RDFC4QwUHSAAwA+C wHCBODzAy8kKVQApwRG/iltIxM5oMQgH0cQryJ3OHDFqByTosEICK1Ag2bhHOKuAzGACUIEgK/tI AxANZDDBIAjMM/EJFnMXowLYgRwFvYJEIYUgSCzQgwugNlH0ICIY6QLag9AgDswXpHBFlB1w/UwQ 8pr4wc0ShPBclh246IwHJ4iA9BVLYHgkaiFMUMIISQxigWfHhrBAER1otUyMQ3TdwdcrFOICFEfw MAjqVYwYVgcwOEtxBUBW7cylCixduInldjDvM38Hae1zO5+A3xHBF2JCNKVnAYGwg9yQsDN407BA EyDQG8IPX3J9xBD7gn1k//AEkNBEiA4AsEOMPMQLwwJw3xlisRdEASqQHQzxTO8f+C3ICg5IwQWa MDZBeAg7SflUB4IgggQIYnnQQNEINjCDynVAAx1gAEPkEaMbKMAZK6CLArBlgiYsAEMlKh3sLvAv 3wHAZi7gAQ/QZoEjmMcDAOAbAXrQA3E8wRkFIAADTGCCL63sCD3gkp98JQiuUWAFBeugA2LgARrs QIEfAADH9gUNKdwACDiAAAumdkEMRkEi9iPE2960gxWIgwC3CEEVKDAnir1HECeogAgCNggM8ABp IYBCDx6HLRKRoFsmwM7EPjDDQlhgARcoAJDUEi8X9CdEg7gCCQhWgGOd7v92dBmBABrQpkEkYSAe WMACrsCAVjLABrA8QQiW4AwFSCBWJ4ABuKrwhBB8AgoFeMIv2rMDI9gAFA7QwREQEAIX0CBMUuDB DohAg7dh4ANSoAENrlANQvEpCiKIgizfdgIHLIBeoWAALVZFywtUQVcnkIBsnBCoFPAACXyyAdeg AJQACAACFSSEBpiAQQmQ4EU+wsc8ePiQKnjGMz1w6Dx0UAWJmqYvzuBhmbby0M1gRwp0mcIGNjCA CLhJEFRQQeUw4Bz8VMilTZqOZkIzmJhetEKAsU5NnVEFx2VgpA7bESEOMAUUME1/xEkqbWz6jCYU AShAECUOBhCAJKhnqAH/CMDUboAAjSn1q0ptggECpgIICGCqU7CqIoCgghlMAYM3MBBfwErXtpBA BjFiwgAEsIESzCACQk1EDpiQAbf25gnuGs10uiMhnDoWPIylzkWd9AwdCGEugkDBAEZqhQFggQkn ZURKMzCCDDBBEAQgggyGMNfFJkYmjYXsa2dLoSXxNCoxAsIUGjBSCAwgAxGgwlUbkYMktHUAI5gC GW/AgCCAwKJ1BWsTnLAECbSwAygYgRU4+9vghjYSrIlABgYwALdaMEhXgEECeNDa6LqlB0NYgjjF oYEszGC7G8BBA0aAhSy4phdlYcIUZjCABnSXjEGKpwOkAA+muneAVfhB/xGCcAW5DeIAARgABEaK gxL8VgVMOMtQNECFLAy4wPtlk1rVhYErRMEB7oBCz+r6JycMIQEfgI8N4FYXFGBhBCXAQW9TDOIk BHYoF6QCClTwYxQTOcTquUEITnAFCSAABh/QghCEsIIhOIEHFdXoMnTAw4ryAAo/WMEKpLAEIwQB CURo1IgIMQEUTGEEDbCCkMPo4RlgQQXKwSCSFVGWJDCByQRugKIN/NsAgHgCw40eHH2pzVVZuha2 IABADKGBJNiZBSMYQJDzi4MOG9jPgObNdwe9iEIzwcQsmEGoG1CCWtfawCOYQQYy4OgsZIEJSQg2 EDRA7GJrYAITOAAKUJoQgSlggQWkLXAJrKDnUuPACiXAtZ+n8Gsjr5rVkiAHFZQdARUEoLChRvG0 bc3udtua2vC2AgSsDQF4Z5u8uc4AFqYQARQcwMgiBvegywKEYL86CyqYgrOhTdoRODzd5I04vh+u 6wywIKtTUIGvmfBvswhF4CAXLDnMAgQqBNvgTEi5ylcO7GAjmzICqUrIZz6JmNv85jR/RCAAADs= ------=_NextPart_94915C5ABAF209EF376268C8-- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Feb 11 07:43:53 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 HAA01997 for ; Tue, 11 Feb 2003 07:43:51 -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 h1BCgUSQ011598 for ; Tue, 11 Feb 2003 04:42:40 -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 h1BCg8bF013897 for ; Tue, 11 Feb 2003 04:42:09 -0800 (PST) Received: from stewart.chicago.il.us ([67.38.193.238]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1BCgPxL007696 for ; Tue, 11 Feb 2003 04:42:25 -0800 (PST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1BCdTYq002091; Tue, 11 Feb 2003 06:39:30 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E48EF01.9080502@stewart.chicago.il.us> Date: Tue, 11 Feb 2003 06:39:29 -0600 From: Randall Stewart 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: TSV WG list , SCTP Implementors Subject: A question of Un-Ordered SCTP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all: In working with the RDDP adaption for SCTP one of the things my co-authors and I have discussed is the 16bit SSN number when sending a "unordered" message. I have thought on this pro's/con's and would like to hear your feedback... Currently the sender of a Unordered data chunk sets the SSN to 0 and the receiver of the Unordered data chunk ignores the contents of the field.. What has been discussed is, "could we instead allow the ULP to specify a value to be set in the SSN and sent in that field with the receiving SCTP to continue to ignore the value but instead pass it, as is, to the ULP" Now, the more I have thought on this the more I think that it is rather harmless for the following reasons: a) Currently receivers are ignoring the SSN, they have to be otherwise they could not process the unordered data properly. b) The sending side API is pretty much in place for this since the send_rcv_info structure (in the socket api) includes the SSN which currently on sending is ignored. c) It seems to me that these 16 bits are just wasted bandwidth and with minor changes to most implementations it would allow useage of these bits in other situations besides RDDP.. So what do all think of the idea? Good? Bad? Thanks R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Feb 11 08:27:00 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 IAA04153 for ; Tue, 11 Feb 2003 08:26: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-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1BDQxB6025881 for ; Tue, 11 Feb 2003 05:26:59 -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 h1BDR6TS025866 for ; Tue, 11 Feb 2003 05:27:07 -0800 (PST) Received: from gw.openss7.com (IDENT:fCK8i7Hh7R1Rf24onrCrFoVe1WnzeVkY@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1BDPhwr027527 for ; Tue, 11 Feb 2003 05:25:43 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:ki4D626Scye5ygHzfu/tP+eIKYZa54/n@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1BDMgD28282; Tue, 11 Feb 2003 06:22:42 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1BDMgn06558; Tue, 11 Feb 2003 06:22:42 -0700 Date: Tue, 11 Feb 2003 06:22:42 -0700 From: "Brian F. G. Bidulock" To: Randall Stewart Cc: TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030211062242.A5719@openss7.org> Reply-To: bidulock@openss7.org References: <3E48EF01.9080502@stewart.chicago.il.us> 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: <3E48EF01.9080502@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Tue, Feb 11, 2003 at 06:39:29AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, Bits inside of chunk headers should be used by SCTP and not by the ULP. The DATA chunk payload is for use by the ULP. If the use of these bits was to be interpreted by SCTP, I would say ok. But because they would be transparent to SCTP, muddling user data and SCTP protocol bits in the header of a DATA chunk is not very clean. User headers transparent to SCTP should be in the data payload. My $0.02 --brian On Tue, 11 Feb 2003, Randall Stewart wrote: > Hi all: > > In working with the RDDP adaption for SCTP one of the things > my co-authors and I have discussed is the 16bit SSN number when > sending a "unordered" message. > > I have thought on this pro's/con's and would like to hear > your feedback... > > Currently the sender of a Unordered data chunk sets the > SSN to 0 and the receiver of the Unordered data chunk ignores > the contents of the field.. > > What has been discussed is, "could we instead allow the > ULP to specify a value to be set in the SSN and sent > in that field with the receiving SCTP to continue to ignore the > value but instead pass it, as is, to the ULP" > > Now, the more I have thought on this the more I think that > it is rather harmless for the following reasons: > > a) Currently receivers are ignoring the SSN, they have to > be otherwise they could not process the unordered data > properly. > > b) The sending side API is pretty much in place for this > since the send_rcv_info structure (in the socket api) includes > the SSN which currently on sending is ignored. > > c) It seems to me that these 16 bits are just wasted bandwidth > and with minor changes to most implementations it would allow > useage of these bits in other situations besides RDDP.. > > > So what do all think of the idea? Good? Bad? > > > Thanks > > R > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > _______________________________________________ > 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-msg-core-4.cisco.com Tue Feb 11 11:50:21 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 LAA11125 for ; Tue, 11 Feb 2003 11:50: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-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1BGiiap014295 for ; Tue, 11 Feb 2003 08:44:44 -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 h1BGiNSB001517 for ; Tue, 11 Feb 2003 08:44:23 -0800 (PST) Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1BGibxL015413 for ; Tue, 11 Feb 2003 08:44:39 -0800 (PST) Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id IAA25153; Tue, 11 Feb 2003 08:23:11 -0800 (PST) Received: by xbl.ma.emulex.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Feb 2003 11:23:10 -0500 Message-ID: <3356669BBE90C448AD4645C843E2BF289B8FEA@xbl.ma.emulex.com> From: "Williams, Jim" To: "'Randall Stewart'" , TSV WG list , SCTP Implementors Subject: RE: [Tsvwg] A question of Un-Ordered SCTP Date: Tue, 11 Feb 2003 11:23:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Randall Stewart [mailto:randall@stewart.chicago.il.us] > Sent: Tuesday, February 11, 2003 7:39 AM > To: TSV WG list; SCTP Implementors > Subject: [Tsvwg] A question of Un-Ordered SCTP > > > Hi all: > > In working with the RDDP adaption for SCTP one of the things > my co-authors and I have discussed is the 16bit SSN number when > sending a "unordered" message. > > I have thought on this pro's/con's and would like to hear > your feedback... > > Currently the sender of a Unordered data chunk sets the > SSN to 0 and the receiver of the Unordered data chunk ignores > the contents of the field.. For SCTP to provide unordered but sequenced delivery seems like a useful and constructive feature. This would require that a sequence number (rather than zero) is placed in SSN on transmit, and and passed to application on receive. This is exactly what RDDP requires, and seems like a general mechanism that would have uses beyond RDDP. The problem, is that it would be a change to SCTP, and RDDP if it relied on this feature would not work with implementations of SCTP that did not support it. However it is a rather trivial change to implementations that could be adopted quite quickly. On balance, I would support this change to SCTP provided there is sentiment that this would be useful beyond just RDDP. From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Feb 12 11:08:27 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 LAA07493 for ; Wed, 12 Feb 2003 11:08: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-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1CG6Esv003923 for ; Wed, 12 Feb 2003 08:06:14 -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 h1CG6PTf010592 for ; Wed, 12 Feb 2003 08:06:25 -0800 (PST) Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1CG4r6E013367 for ; Wed, 12 Feb 2003 08:04:54 -0800 (PST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id KAA21085; Wed, 12 Feb 2003 10:45:18 -0500 (EST) Message-ID: <3E4A6C0E.5080104@ulticom.com> Date: Wed, 12 Feb 2003 10:45:18 -0500 From: David Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Stewart CC: TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <3E48EF01.9080502@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randall Stewart wrote: > Currently the sender of a Unordered data chunk sets the > SSN to 0 and the receiver of the Unordered data chunk ignores > the contents of the field.. When did this change? RFC 2960, section 6.6 states, The 'Stream Sequence Number' field in a DATA chunk with U flag set to 1 has no significance. The sender can fill it with arbitrary value, but the receiver MUST ignore the field. Where is it stated that the SSN should be set to zero for unordered data chunks? -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Feb 12 14:15:34 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 OAA12503 for ; Wed, 12 Feb 2003 14:15: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-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1CJDESQ019672; Wed, 12 Feb 2003 11:13: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 ADF85152; Wed, 12 Feb 2003 11:13:12 -0800 (PST) Message-ID: <3E4A9CC8.9080100@cisco.com> Date: Wed, 12 Feb 2003 13:13:12 -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: David Lehmann CC: Randall Stewart , TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <3E48EF01.9080502@stewart.chicago.il.us> <3E4A6C0E.5080104@ulticom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Lehmann wrote: > Randall Stewart wrote: > >> Currently the sender of a Unordered data chunk sets the >> SSN to 0 and the receiver of the Unordered data chunk ignores >> the contents of the field.. > > > When did this change? RFC 2960, section 6.6 states, > The 'Stream Sequence Number' field in a DATA chunk with U flag set to > 1 has no significance. The sender can fill it with arbitrary value, > but the receiver MUST ignore the field. > > Where is it stated that the SSN should be set to zero for unordered data > chunks? > Your correct.. it is an arbitrary value.. 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-2.cisco.com Sat Feb 15 13:49:08 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 NAA06219 for ; Sat, 15 Feb 2003 13:49:07 -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 h1FIm7sv025299 for ; Sat, 15 Feb 2003 10:48:07 -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 h1FImJGJ011954 for ; Sat, 15 Feb 2003 10:48:19 -0800 (PST) Received: from gw.openss7.com (IDENT:BIdtU2Qruz3vRa5uekg/P7cxIVyi0Ews@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1FIkobJ009708 for ; Sat, 15 Feb 2003 10:46:50 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:YUJMyE62d6qZtR4yM9d+lKK2qdYFqozK@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1FIhsD27351; Sat, 15 Feb 2003 11:43:54 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1FIhrw18199; Sat, 15 Feb 2003 11:43:53 -0700 Date: Sat, 15 Feb 2003 11:43:53 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: David Lehmann , Randall Stewart , TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030215114353.B17855@openss7.org> Reply-To: bidulock@openss7.org References: <3E48EF01.9080502@stewart.chicago.il.us> <3E4A6C0E.5080104@ulticom.com> <3E4A9CC8.9080100@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: <3E4A9CC8.9080100@cisco.com>; from rrs@cisco.com on Wed, Feb 12, 2003 at 01:13:12PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, Meaning most of the argument for backwards compatability vaporizes... INIT negotiation will be required for an unordered data chunk approach, but would not be necessary for an ordered data chunk approach. --brian On Wed, 12 Feb 2003, Randall Stewart (cisco) wrote: > David Lehmann wrote: > > > Randall Stewart wrote: > > > >> Currently the sender of a Unordered data chunk sets the > >> SSN to 0 and the receiver of the Unordered data chunk ignores > >> the contents of the field.. > > > > > > When did this change? RFC 2960, section 6.6 states, > > The 'Stream Sequence Number' field in a DATA chunk with U flag set to > > 1 has no significance. The sender can fill it with arbitrary value, > > but the receiver MUST ignore the field. > > > > Where is it stated that the SSN should be set to zero for unordered data > > chunks? > > > Your correct.. it is an arbitrary value.. > > R > > -- > 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-msg-core-3.cisco.com Sat Feb 15 15:29:21 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 PAA07090 for ; Sat, 15 Feb 2003 15:29:20 -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 h1FKTJB6000820 for ; Sat, 15 Feb 2003 12:29: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 h1FKTRWX013696 for ; Sat, 15 Feb 2003 12:29:28 -0800 (PST) Received: from stewart.chicago.il.us ([67.38.193.238]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1FKRxbJ020965 for ; Sat, 15 Feb 2003 12:27:59 -0800 (PST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1FKP52k006539; Sat, 15 Feb 2003 14:25:06 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E4EA221.8050809@stewart.chicago.il.us> Date: Sat, 15 Feb 2003 14:25:05 -0600 From: Randall Stewart 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: "Randall Stewart (cisco)" , David Lehmann , TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <3E48EF01.9080502@stewart.chicago.il.us> <3E4A6C0E.5080104@ulticom.com> <3E4A9CC8.9080100@cisco.com> <20030215114353.B17855@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, > > Meaning most of the argument for backwards compatability vaporizes... > And what pre-tell do you mean by "backwards compatability vaporizes"? RFC2960 basically says that an arbitrary value is put in the SSN. It seems to me that if my implementation wants to number each SSN that is un-ordered .. then that qualify's as an arbitrary value. If we call that a feature it does not break any backward compatability... and the only way it would effect the peer is if it was looking inside the SSN (which it is prohibited from doing). Now the only issue would be if the peer bothered to deliver the "arbitrary value" to the ULP. > INIT negotiation will be required for an unordered data chunk approach, > but would not be necessary for an ordered data chunk approach. > I don't see why negotiation is needed. It would be nice if I notified my peer that I could do something, aka, I number my unordered data, but telling you I am going to do something with a "arbitrary value" is far from negotiation... The only real issue would be if the peer delivered the SSN up to the ULP (as I said above). Which I would bet most implementations do.. since it is more work to NOT deliver the SSN and special case the code. I know I deliver what ever junk is in the SSN... it was easier... R > --brian > > On Wed, 12 Feb 2003, Randall Stewart (cisco) wrote: > > >>David Lehmann wrote: >> >> >>>Randall Stewart wrote: >>> >>> >>>>Currently the sender of a Unordered data chunk sets the >>>>SSN to 0 and the receiver of the Unordered data chunk ignores >>>>the contents of the field.. >>> >>> >>>When did this change? RFC 2960, section 6.6 states, >>> The 'Stream Sequence Number' field in a DATA chunk with U flag set to >>> 1 has no significance. The sender can fill it with arbitrary value, >>> but the receiver MUST ignore the field. >>> >>>Where is it stated that the SSN should be set to zero for unordered data >>>chunks? >>> >> >>Your correct.. it is an arbitrary value.. >> >>R >> >>-- >>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 > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Sat Feb 15 19:17:42 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 TAA09048 for ; Sat, 15 Feb 2003 19:17:40 -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 h1G0Fasv005748 for ; Sat, 15 Feb 2003 16:15:36 -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 h1G0FmE6021649 for ; Sat, 15 Feb 2003 16:15:48 -0800 (PST) Received: from gw.openss7.com (IDENT:jzp3wmwr8GCN3AREk+ifV9dYYjfUGnxX@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1G0Fh7N021726 for ; Sat, 15 Feb 2003 16:15:43 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:9pJIkRw3mXLqmQ22dhN1m2bLt4SBpzqH@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1G0AYD31496; Sat, 15 Feb 2003 17:10:34 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1G0AXN24764; Sat, 15 Feb 2003 17:10:33 -0700 Date: Sat, 15 Feb 2003 17:10:33 -0700 From: "Brian F. G. Bidulock" To: Randall Stewart Cc: "Randall Stewart (cisco)" , David Lehmann , TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030215171033.A24180@openss7.org> Reply-To: bidulock@openss7.org References: <3E48EF01.9080502@stewart.chicago.il.us> <3E4A6C0E.5080104@ulticom.com> <3E4A9CC8.9080100@cisco.com> <20030215114353.B17855@openss7.org> <3E4EA221.8050809@stewart.chicago.il.us> 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: <3E4EA221.8050809@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Sat, Feb 15, 2003 at 02:25:05PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Sat, 15 Feb 2003, Randall Stewart wrote: > Brian F. G. Bidulock wrote: > > Randall, > > > > Meaning most of the argument for backwards compatability vaporizes... > > > > And what pre-tell do you mean by "backwards compatability vaporizes"? Pray-tell? > > RFC2960 basically says that an arbitrary value is put in the SSN. It > seems to me that if my implementation wants to number each SSN that is > un-ordered .. then that qualify's as an arbitrary value. If we call > that a feature it does not break any backward compatability... and the > only way it would effect the peer is if it was looking inside the > SSN (which it is prohibited from doing). Now the only issue would > be if the peer bothered to deliver the "arbitrary value" to the > ULP. The receiver cannot detect a modified SCTP by observing non-zero values in the SSN of unordered chunks. > > > INIT negotiation will be required for an unordered data chunk approach, > > but would not be necessary for an ordered data chunk approach. > > > > I don't see why negotiation is needed. It would be nice if I notified my > peer that I could do something, aka, I number my unordered data, but > telling you I am going to do something with a "arbitrary value" is > far from negotiation... The negotiation is: A tells B that it supports it and B tells A that it supports it. Otherwise, the modification is unsupported for ths association. A telling B and just numbering its SSNs acheives nothing. > > The only real issue would be if the peer delivered the SSN up to the > ULP (as I said above). Which I would bet most implementations > do.. Because SSN is monotonitcally increasing from zero on ordered data and the data is reliably delivered, there is no need to deliver SSN even of ordered data. For unordered data it is arbitrary and does not need to be delivered either. Nevertheless, if RDDP needs SSN and runs as a ULP, it would have to place this requirement on the SCTP ULP interface, regardless of whether it is order of arrival deliverery of ordered data chunks or delivery of unordered data chunks with modified SSNs. > since it is more work to NOT deliver the SSN and special > case the code. I know I deliver what ever junk is in the > SSN... it was easier... It is not more work not to deliver the SSN, you are making a presumpltion based on your implementation. In our implementation it must be requested and requires more work on each delivery (delivering the SSN when data will do) and is only applicable to ordered data. This is because SSN is an internal number for use by SCTP as defined in the RFC and has no use to applications. If unordered data is used by RDDP to perform its own reordering, RDDP will be unable to send unordered data using SCTP in the same fashion as today. (Some implementations expedite unordered data ahead of ordered data for such applications as SIGTRAN or other POC applications) If ordered data (with order of arrival delivery) is used for RDDP, RDDP will still be able to send unordered data which is expedited around ordered data for SIGTRAN/POC applications. Is there some reason to keep these applications from being able to use DDP effectively? I really think that it would be more useful to put RDDP "inside" SCTP rather than "above" SCTP. If RDDP information is placed at the beginning of ordered data chunks, SCTP could perform direct data placement internally on data sent from peers supporting the procedure and perform normal ordered delivery on those that do not. Modified SCTP receivers would perform DDP and strip the DDP header from the data. Unmodified SCTP receivers receiving DDP data chunks would ignore and deliver the DDP header prefixed to the data. Then if it can also support order of arrival delivery of ordered data, it can use an RDDP as a layer above SCTP to do placement based on the header in the data. Such an arrangement would still supported expedited delivery of out of order data. --brian > > R > > > --brian > > > > On Wed, 12 Feb 2003, Randall Stewart (cisco) wrote: > > > > > >>David Lehmann wrote: > >> > >> > >>>Randall Stewart wrote: > >>> > >>> > >>>>Currently the sender of a Unordered data chunk sets the > >>>>SSN to 0 and the receiver of the Unordered data chunk ignores > >>>>the contents of the field.. > >>> > >>> > >>>When did this change? RFC 2960, section 6.6 states, > >>> The 'Stream Sequence Number' field in a DATA chunk with U flag set to > >>> 1 has no significance. The sender can fill it with arbitrary value, > >>> but the receiver MUST ignore the field. > >>> > >>>Where is it stated that the SSN should be set to zero for unordered data > >>>chunks? > >>> > >> > >>Your correct.. it is an arbitrary value.. > >> > >>R > >> > >>-- > >>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 > > > > > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) -- 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 Sat Feb 15 20:43:47 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 UAA09745 for ; Sat, 15 Feb 2003 20:43:45 -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 h1G1hPsv024748; Sat, 15 Feb 2003 17:43:25 -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 ADL25459; Sat, 15 Feb 2003 17:43:37 -0800 (PST) Message-ID: <3E4EECC8.70007@cisco.com> Date: Sat, 15 Feb 2003 19:43: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: Randall Stewart , David Lehmann , TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <3E48EF01.9080502@stewart.chicago.il.us> <3E4A6C0E.5080104@ulticom.com> <3E4A9CC8.9080100@cisco.com> <20030215114353.B17855@openss7.org> <3E4EA221.8050809@stewart.chicago.il.us> <20030215171033.A24180@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: > > >The receiver cannot detect a modified SCTP by observing non-zero values >in the SSN of unordered chunks. > > I don't see this to be a problem. If the receiver needs this service it won't be running on that implementaition very long :> And I would think we could add one of the HAVE_SCTP_UNORDERED_SEQ flags to the socketapi draft... (HAVE_SCTP and some others will be showing up in the next version). > > >>>INIT negotiation will be required for an unordered data chunk approach, >>>but would not be necessary for an ordered data chunk approach. >>> >>> >>> >>I don't see why negotiation is needed. It would be nice if I notified my >>peer that I could do something, aka, I number my unordered data, but >>telling you I am going to do something with a "arbitrary value" is >>far from negotiation... >> >> > >The negotiation is: A tells B that it supports it and B tells A that it >supports it. Otherwise, the modification is unsupported for ths >association. > > I don't think this is negotiation.. my interpretation of negotiation is something more akin to what DCCP does... or PPP... >A telling B and just numbering its SSNs acheives nothing. > > > Depending on B's implementation yes.. but a lot of things depend on implementations... >>The only real issue would be if the peer delivered the SSN up to the >>ULP (as I said above). Which I would bet most implementations >>do.. >> >> > >Because SSN is monotonitcally increasing from zero on ordered data and >the data is reliably delivered, there is no need to deliver SSN even of >ordered data. For unordered data it is arbitrary and does not need to >be delivered either. > >Nevertheless, if RDDP needs SSN and runs as a ULP, it would have to >place this requirement on the SCTP ULP interface, regardless of whether >it is order of arrival deliverery of ordered data chunks or delivery of >unordered data chunks with modified SSNs. > > That sounds like requirements for the adaption layer draft... > > >>since it is more work to NOT deliver the SSN and special >>case the code. I know I deliver what ever junk is in the >>SSN... it was easier... >> >> > >It is not more work not to deliver the SSN, you are making a >presumpltion based on your implementation. In our implementation it >must be requested and requires more work on each delivery (delivering >the SSN when data will do) and is only applicable to ordered data. This >is because SSN is an internal number for use by SCTP as defined in the >RFC and has no use to applications. > > But it is in the socket api sinfo structure.. and this (for those that meet a socket api) will show up with the stream no.. and all the other fluf.. Of course not everyone supports a socket api.. and thats fine.. those that do would have the SSN as well as the SN. >If unordered data is used by RDDP to perform its own reordering, RDDP >will be unable to send unordered data using SCTP in the same fashion as >today. (Some implementations expedite unordered data ahead of ordered >data for such applications as SIGTRAN or other POC applications) > > But that is NOT specified in the RFC (expidited data). It mentions it yes, but this again would depend on the implementation... One would need the equivalant of a HAVE_UNORDERED_EXPIDITE in ones flags to recognize your implementation did this... Sigtran MAY have made such a requirments in some of its adaption layers.. But this is not standard in SCTP.. I see no reason that RDDP could not require it... And I don't see that your statement "RDDP will be unable to send unordered data" is true. Currently it is a "undefined value" and it has no meaning per requirment EXPIDITED as you elude to or otherwise. If RDDP sent unordered data with sequences this is COMPLETELY within valid scope of RFC2960. It is unknown if the receiver will ever be able to see what was in that field.. but it IS conformant to RFC2960 if a RDDP-SCTP implementation numbered each of its unordered data in a stream... nothing wrong with that.. If you think so, please direct me to the MUST (or SHOULD for that matter) in 2960 that tells me I can't sequence my outgoing unordered data.... >If ordered data (with order of arrival delivery) is used for RDDP, RDDP > What is "ordered data (with order of arrival delivery"? This does NOT exist in 2960. You either get unordered, or SCTP must hold the data in stream and re-sequence.. anything else is NOT in conformance with 2960.. >will still be able to send unordered data which is expedited around >ordered data for SIGTRAN/POC applications. Is there some reason to keep >these applications from being able to use DDP effectively? > > There is NO "expedited" data requirement in 2960. You may have implemented such a thing.. but this is left open to the implementation in 2960, so you can NOT depend on it... just like you can't depend on a receiver passing along the SSN on a un-ordered message. >I really think that it would be more useful to put RDDP "inside" SCTP >rather than "above" SCTP. If RDDP information is placed at the >beginning of ordered data chunks, SCTP could perform direct data >placement internally on data sent from peers supporting the procedure >and perform normal ordered delivery on those that do not. Modified SCTP >receivers would perform DDP and strip the DDP header from the data. >Unmodified SCTP receivers receiving DDP data chunks would ignore and >deliver the DDP header prefixed to the data. Then if it can also >support order of arrival delivery of ordered data, it can use an RDDP as > Please show me where this new feature is you mention in 2960.. I don't see it anywhere... R >a layer above SCTP to do placement based on the header in the data. >Such an arrangement would still supported expedited delivery of out of >order data. > >--brian > > > >>R >> >> >> >>>--brian >>> >>>On Wed, 12 Feb 2003, Randall Stewart (cisco) wrote: >>> >>> >>> >>> >>>>David Lehmann wrote: >>>> >>>> >>>> >>>> >>>>>Randall Stewart wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Currently the sender of a Unordered data chunk sets the >>>>>>SSN to 0 and the receiver of the Unordered data chunk ignores >>>>>>the contents of the field.. >>>>>> >>>>>> >>>>>When did this change? RFC 2960, section 6.6 states, >>>>> The 'Stream Sequence Number' field in a DATA chunk with U flag set to >>>>> 1 has no significance. The sender can fill it with arbitrary value, >>>>> but the receiver MUST ignore the field. >>>>> >>>>>Where is it stated that the SSN should be set to zero for unordered data >>>>>chunks? >>>>> >>>>> >>>>> >>>>Your correct.. it is an arbitrary value.. >>>> >>>>R >>>> >>>>-- >>>>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 >>>> >>>> >>> >>> >>-- >>Randall R. Stewart >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >> >> > > > -- 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 Sun Feb 16 17:47:51 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 RAA00690 for ; Sun, 16 Feb 2003 17:47:50 -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 h1GMgOSQ020924 for ; Sun, 16 Feb 2003 14:42:24 -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 h1GMfwdw010698 for ; Sun, 16 Feb 2003 14:41:58 -0800 (PST) Received: from gw.openss7.com (IDENT:89jpCcq046nzBBjm/Cog9NY2rDwwLD6Y@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id h1GMgcSj001379 for ; Sun, 16 Feb 2003 14:42:38 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:Wp3aZnjLl66BEbnmn6BWrkScb+TuPdkt@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1GMacD20960; Sun, 16 Feb 2003 15:36:39 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1GMac022499; Sun, 16 Feb 2003 15:36:38 -0700 Date: Sun, 16 Feb 2003 15:36:38 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Randall Stewart , David Lehmann , TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030216153638.A22008@openss7.org> Reply-To: bidulock@openss7.org References: <3E48EF01.9080502@stewart.chicago.il.us> <3E4A6C0E.5080104@ulticom.com> <3E4A9CC8.9080100@cisco.com> <20030215114353.B17855@openss7.org> <3E4EA221.8050809@stewart.chicago.il.us> <20030215171033.A24180@openss7.org> <3E4EECC8.70007@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: <3E4EECC8.70007@cisco.com>; from rrs@cisco.com on Sat, Feb 15, 2003 at 07:43:36PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Sat, 15 Feb 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > > > > > >The receiver cannot detect a modified SCTP by observing non-zero values > >in the SSN of unordered chunks. > > > > > I don't see this to be a problem. If the receiver needs this service > it won't be running on that implementaition very long :> > And I would think we could add one of the > > HAVE_SCTP_UNORDERED_SEQ > > flags to the socketapi draft... (HAVE_SCTP and some others > will be showing up in the next version). I never gave the socketapi draft much notice. It largely deviates from POSIX/OpenGroup socket semantics and is, afterall, only a draft of an INFORMATIONAL, so feel free to say whatever you like in the draft. Noone is required to follow it. > > > > > > >>>INIT negotiation will be required for an unordered data chunk approach, > >>>but would not be necessary for an ordered data chunk approach. > >>> > >>> > >>> > >>I don't see why negotiation is needed. It would be nice if I notified my > >>peer that I could do something, aka, I number my unordered data, but > >>telling you I am going to do something with a "arbitrary value" is > >>far from negotiation... > >> > >> > > > >The negotiation is: A tells B that it supports it and B tells A that it > >supports it. Otherwise, the modification is unsupported for ths > >association. > > > > > I don't think this is negotiation.. my interpretation of negotiation is > something more akin to what DCCP does... or PPP... > > > >A telling B and just numbering its SSNs acheives nothing. > > > > > > > > Depending on B's implementation yes.. but a lot of things depend on > implementations... > > >>The only real issue would be if the peer delivered the SSN up to the > >>ULP (as I said above). Which I would bet most implementations > >>do.. > >> > >> > > > >Because SSN is monotonitcally increasing from zero on ordered data and > >the data is reliably delivered, there is no need to deliver SSN even of > >ordered data. For unordered data it is arbitrary and does not need to > >be delivered either. > > > >Nevertheless, if RDDP needs SSN and runs as a ULP, it would have to > >place this requirement on the SCTP ULP interface, regardless of whether > >it is order of arrival deliverery of ordered data chunks or delivery of > >unordered data chunks with modified SSNs. > > > > > That sounds like requirements for the adaption layer draft... Yes, if it needs something it is going to have to say so. > > > > > > >>since it is more work to NOT deliver the SSN and special > >>case the code. I know I deliver what ever junk is in the > >>SSN... it was easier... > >> > >> > > > >It is not more work not to deliver the SSN, you are making a > >presumpltion based on your implementation. In our implementation it > >must be requested and requires more work on each delivery (delivering > >the SSN when data will do) and is only applicable to ordered data. This > >is because SSN is an internal number for use by SCTP as defined in the > >RFC and has no use to applications. > > > > > But it is in the socket api sinfo structure.. and this (for those that > meet a socket api) will show up with the stream no.. and all the > other fluf.. Of course not everyone supports a socket api.. and thats > fine.. those that do would have the SSN as well as the SN. Meet the socket api? Noone is required to follow the socketapi draft. It is not on standards track. I disagree with most (if not all) of the draft on the basis that it violates POSIX/OpenGroup semantics for SOCK_SEQPACKET, but have needed to argue it because the draft is only a draft of an INFORMATIONAL. If you expect implementations to follow the socketapi draft you will have to make it more than INFORMATIONAL, and you will have to advance it to RFC status. > > >If unordered data is used by RDDP to perform its own reordering, RDDP > >will be unable to send unordered data using SCTP in the same fashion as > >today. (Some implementations expedite unordered data ahead of ordered > >data for such applications as SIGTRAN or other POC applications) > > > > > But that is NOT specified in the RFC (expidited data). It mentions it yes, > but this again would depend on the implementation... The RFC does not prohibit it. Those that expedite data (as mentioned, and thus implicitly permitted) will not be able to expedite and use RDDP as well. > One would need the > equivalant of a HAVE_UNORDERED_EXPIDITE in ones flags to > recognize your implementation did this... You are talking that INFORMATIONAL draft again... > Sigtran MAY have made > such a requirments in some of its adaption layers.. But this is not > standard in SCTP.. I see no reason that RDDP could not require > it... Not standard in SCTP? It is not prohibited, so a STANDARD SCTP is permitted to do so. SCTP will permit it, but an unordered approach to RDDP will not. An unorderd approach would. It is simply another failing of the unordered approach. > > And I don't see that your statement > > "RDDP will be unable to send unordered data" > > is true. Currently it is a "undefined value" and it has no > meaning per requirment EXPIDITED as you elude to or otherwise. > If RDDP sent unordered data with sequences this is COMPLETELY > within valid scope of RFC2960. It is unknown if the receiver > will ever be able to see what was in that field.. but it > IS conformant to RFC2960 if a RDDP-SCTP implementation numbered > each of its unordered data in a stream... nothing wrong with > that.. If you think so, please direct me to the MUST (or SHOULD > for that matter) in 2960 that tells me I can't sequence my > outgoing unordered data.... It just simple: as RDDP is going to be ordering unordered data itself, it cannot send unordered data. > > >If ordered data (with order of arrival delivery) is used for RDDP, RDDP > > > What is "ordered data (with order of arrival delivery"? This does NOT exist > in 2960. You either get unordered, or SCTP must hold the data in > stream and re-sequence.. anything else is NOT in conformance with > 2960.. Ok, now you start with the same argument TCP brought up with RDDP. The answer is simple, have RDDP reorder the data "inside" SCTP. > > >will still be able to send unordered data which is expedited around > >ordered data for SIGTRAN/POC applications. Is there some reason to keep > >these applications from being able to use DDP effectively? > > > > > There is NO "expedited" data requirement in 2960. You may have implemented > such a thing.. but this is left open to the implementation in 2960, so > you can > NOT depend on it... just like you can't depend on a receiver passing along > the SSN on a un-ordered message. So what? Implementations that actually do so (and are permitted to do so by RFC 2960) will not be able to use RDDP. If you simply take the ordered data approach rather than try to impose sequence on unordered data, then it is not a problem for implementations that chose to permit expedited data. > > >I really think that it would be more useful to put RDDP "inside" SCTP > >rather than "above" SCTP. If RDDP information is placed at the > >beginning of ordered data chunks, SCTP could perform direct data > >placement internally on data sent from peers supporting the procedure > >and perform normal ordered delivery on those that do not. Modified SCTP > >receivers would perform DDP and strip the DDP header from the data. > >Unmodified SCTP receivers receiving DDP data chunks would ignore and > >deliver the DDP header prefixed to the data. Then if it can also > >support order of arrival delivery of ordered data, it can use an RDDP as > > > Please show me where this new feature is you mention in 2960.. I don't see > it anywhere... That was a proposal, you goof. ;) --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 Feb 16 18:16: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 SAA00966 for ; Sun, 16 Feb 2003 18:16:54 -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 h1GNBfap002461 for ; Sun, 16 Feb 2003 15:11:41 -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 h1GNBeVp023263 for ; Sun, 16 Feb 2003 15:11:41 -0800 (PST) Received: from chimta05.algx.net (mta6.algx.net [67.92.168.235]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1GNABbJ002592 for ; Sun, 16 Feb 2003 15:10:12 -0800 (PST) Received: from emarketing (ip67-94-171-122.z171-94-67.customer.algx.net [67.94.171.122]) by chimmx05.algx.net (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HAF00KWXBF24E@chimmx05.algx.net> for SCTP-IMPL@EXTERNAL.CISCO.COM; Sun, 16 Feb 2003 16:50:13 -0600 (CST) Date: Sun, 16 Feb 2003 17:52:11 -0500 From: David Dickson Subject: Homeland Defense - Outlook & Grants Workshop, L.A., San Fran, Phila-April 2003 To: SCTP-IMPL@EXTERNAL.CISCO.COM Message-id: <4132301-220032016225211480@emarketing> Organization: Market*Access MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT To: SCTP-IMPL@EXTERNAL.CISCO.COM Homeland Defense Training Conference Forecast and Budget Outlook And Grants Workshops With special tracks addressing... * Grants Workshop for State and Local Municipalities with expanded proposal tips and grants ID techniques (All sessions) * Technology and R&D Business Opportunities (All sessions) * Risk Minimization and Avoidance for Government and Corporate Executives (All Sessions) * Corporate and HR Workplace Strategies for Dealing with Anthrax, Smallpox, and Other Biological/Chemical Threats (San Fran and Philadelphia) 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. **** SPECIAL EXHIBITOR OPPORTUNITIES AVAILABLE. CALL DONNA ANDERSON AT 703-807-2740 FOR DETAILS. **** In January 2003 this conference was held in Colorado Springs with 600 attendees. In early February 2003 this conference was held in Washington, D.C. with over 400 attendees. Both conferences sold out. Sign up early as we expect each of these to sell out. Budget and Outlook -- Morning Session (L.A., San Fran and Philadelphia) 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. Invited speakers include: * FEMA * EPA * Department of Justice - FBI * Army * State Emergency Management Executives * State Government Grants Managers * Department of Health and Human Services * Food and Drug Administration * Department of Homeland Security Grants Workshop -- Afternoon Track 1(LA, San Fran and Philadelphia) 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. Grants Workshop Speakers include: * First Responder Grants, FEMA * 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) Technology and R&D Business Opportunities - Afternoon Track 2 (LA, San Fran and Philadelphia) The speakers will represent DoD, federal 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. Opportunities to be covered include bio-technology, R&D, information technology, cyber security, infrastructure protection. Names will be posted at this web site when confirmed. Risk Minimization and Avoidance for Government and Corporate Executives Afternoon Track 3 (LA, San Francisco and Philadelphia) 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 Corporate and HR Workplace Strategies for Dealing with Anthrax, Smallpox, and Other Biological/Chemical Threats Afternoon Track 4 (San Francisco and Philadelphia) This workshop will review the specific threats of various biological and chemical agents and how these threats might arise in the workplace. A special emphasis will be placed on contingency plans for suspected Anthrax contamination and workplaces that have been inadvertently exposed to the vaccinia virus because of direct OR third-party contact with recipients of the smallpox vaccine. We will address the "nuts and bolts" of how a company should prepare for such scenarios, including who to call and what to do in the event of contamination or infection. The workshop will also provide an overview of the legal ramifications, including a breakdown of when workers compensation insurance will respond to employee injury and how best to limit liability through workplace education and proper planning. The hospital response to the federal smallpox vaccination program will also be examined. 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 * 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 * Perseus Development Corporation *** 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. Cancellations will be accepted up to 48 hours prior to the conference with full refund less a $50 processing fee. Within 48 hours, no refund. Refunds will be processed within 10 days after the event. Final speaker lists, agenda and important hotel information is at our web site. Call our information hot line at 703-807-2027 for information on how to register on-line and obtain up to date conference information. If you wish to be REMOVED from this list, please REPLY to this message and place REMOVE in the SUBJECT line. This is a business communication and we do not wish to send you an email message if you do not wish to receive one. Thank you. From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Feb 17 02:47:16 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 CAA16921 for ; Mon, 17 Feb 2003 02:47:15 -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 h1H7gUSQ022213 for ; Sun, 16 Feb 2003 23:42: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 h1H7gUYY011885 for ; Sun, 16 Feb 2003 23:42:30 -0800 (PST) Received: from web41302.mail.yahoo.com (web41302.mail.yahoo.com [66.218.93.51]) by proxy3.cisco.com (8.12.2/8.11.2) with SMTP id h1H7gkSj011916 for ; Sun, 16 Feb 2003 23:42:46 -0800 (PST) Message-ID: <20030217073910.21089.qmail@web41302.mail.yahoo.com> Received: from [210.3.50.157] by web41302.mail.yahoo.com via HTTP; Sun, 16 Feb 2003 23:39:10 PST Date: Sun, 16 Feb 2003 23:39:10 -0800 (PST) From: "K. Poon" Subject: Re: A question of Un-Ordered SCTP To: Randall Stewart , TSV WG list , SCTP Implementors In-Reply-To: <3E48EF01.9080502@stewart.chicago.il.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- Randall Stewart wrote: > What has been discussed is, "could we instead allow the > ULP to specify a value to be set in the SSN and sent > in that field with the receiving SCTP to continue to ignore the > value but instead pass it, as is, to the ULP" Do you mean the sinfo_ssn field in the sctp_sndrcvinfo structure? I believe it is specified to be not "writeable" on the send side. And I think that it is best not to be "writeable" by socket apps. SSN is a SCTP internal concept. It should not be "changeable" by an app. To me, even the receiver should not need to see it at all. It is there now, if I remember correctly, simply because of the requirement of returning unsent data. Please correct me if I am wrong. > Now, the more I have thought on this the more I think that > it is rather harmless for the following reasons: There are a lot of harmless things, it does not mean that we need to do them all, although it is just code (-: > a) Currently receivers are ignoring the SSN, they have to > be otherwise they could not process the unordered data > properly. This just means that the SSN field is not used in this situation by SCTP. It does not argue for the use of the field by ULP... To me, this is a semantic overload of the SSN field. It is really not a good idea in protocol design, especially if the overload is for the sake of an ULP. > b) The sending side API is pretty much in place for this > since the send_rcv_info structure (in the socket api) includes > the SSN which currently on sending is ignored. The sinfo_ssn is there because of simplicity reason. We don't want to have different data structures for send and receive. I guess this should not be used as a reason for letting an app change an internal SCTP concept. > c) It seems to me that these 16 bits are just wasted bandwidth > and with minor changes to most implementations it would allow > useage of these bits in other situations besides RDDP.. Is this similar in suggesting that since there are some bits unused (wasted) in the TCP reserved bit field, we should allow an app to set whatever value it likes in those bits? This may sound a little bit extreme, but the idea is similar. I believe if it is allowed, it will be a very bad precedence in SCTP protocol development. We should not encourage app protocol to "require" changes in SCTP simply because it is "convenient" and "harmless" while it is just a simple matter to support the changes in the app protocol itself. > So what do all think of the idea? Good? Bad? Just my $0.02, I think it is a bad idea... ===== K. Poon. kcpoon@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Feb 17 04:48:16 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 EAA18699 for ; Mon, 17 Feb 2003 04:48: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 h1H9hQap008211 for ; Mon, 17 Feb 2003 01:43: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 h1H9hP6J008823 for ; Mon, 17 Feb 2003 01:43:25 -0800 (PST) Received: from parmesan.cs.wisc.edu (parmesan.cs.wisc.edu [128.105.167.16]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1H9hH7N013414 for ; Mon, 17 Feb 2003 01:43:18 -0800 (PST) Received: (from poon@localhost) by parmesan.cs.wisc.edu (8.9.2/8.9.2) id DAA13013; Mon, 17 Feb 2003 03:27:30 -0600 (CST) Date: Mon, 17 Feb 2003 03:27:30 -0600 (CST) From: Kacheong Poon Message-Id: <200302170927.DAA13013@parmesan.cs.wisc.edu> To: cait@asomi.com, tsvwg@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Cc: sctp-impl@external.cisco.com Included message from Caitlin Bestler : >---- >So, trying to work with SCTP on SCTP's terms, you have three >possible strategies: > >-- Include a SSN-equivalent in the Data Chunk. > >-- Allow out-of-order placement of ordered Data chunks. > >-- Make SCTP's SSN meaningful for unordered delivery. > >The pure ULP solution obviously has the least impact on >the SCTP layer. But it smacks of having the ULP duplicate >functionality that rightfully belongs at the transport >layer. I believe the quick consenseus is that sequenced >unordered delivery is a natural concept that has value >beyond any single ULP. I don't think that the above functionality "rightfully belongs to the transport layer (SCTP in this case)." To me, the unordered delivery mechanism as specified in RFC 2960 simply means that such data chunks can be delivered in whatever order the receiver wants. This also automatically means that the sender can send such chunks in whatever order it wants if it deems necessary. For example, an implementation can choose to place a smaller unordered data chunk ahead in the send queue before a bigger unordered data chunk. Assuming that the SSN is assigned when data chunk is sent, to make the suggested change to RFC 2960 to an implementation may mean more than what has been discussed. And it is really a protocol change, not just implementation's choice of how to generate "arbitrary numbers" to be put in the SSN field of unordered chunk as it actually places extra restrictions on how an implementation handled such chunks as described above. The SSN in SCTP is designed to be used for order of delivery by SCTP, that's why it is ignored for unordered delivery. If an ULP wants to have ordered delivery, don't use this feature of SCTP. If an ULP wants unordered delivery, but it still wants to know the sender's sending order, just place its own sequence number. Overloading the SSN in SCTP, even if it is assigned by SCTP, not by ULP, is really a bad design choice. Anyway, just my $0.02. BTW, I also cc the SCTP implementors' list. I believe people there should be aware of such things. I don't know why that list was removed from the cc list... >---- K. Poon. From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Feb 17 11:30:50 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 LAA25275 for ; Mon, 17 Feb 2003 11:30:49 -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 h1HGPAsv018970 for ; Mon, 17 Feb 2003 08:25:10 -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 h1HGOw0Q009430 for ; Mon, 17 Feb 2003 08:24:58 -0800 (PST) Received: from stewart.chicago.il.us ([67.38.193.238]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1HGPHQC007229 for ; Mon, 17 Feb 2003 08:25:17 -0800 (PST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1HGJ72k009705; Mon, 17 Feb 2003 10:19:08 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E510B7B.50803@stewart.chicago.il.us> Date: Mon, 17 Feb 2003 10:19:07 -0600 From: Randall Stewart 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: Kacheong Poon CC: cait@asomi.com, tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <200302170927.DAA13013@parmesan.cs.wisc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kacheong Poon wrote: > Included message from Caitlin Bestler : > > >>---- >>So, trying to work with SCTP on SCTP's terms, you have three >>possible strategies: >> >>-- Include a SSN-equivalent in the Data Chunk. >> >>-- Allow out-of-order placement of ordered Data chunks. >> >>-- Make SCTP's SSN meaningful for unordered delivery. >> >>The pure ULP solution obviously has the least impact on >>the SCTP layer. But it smacks of having the ULP duplicate >>functionality that rightfully belongs at the transport >>layer. I believe the quick consenseus is that sequenced >>unordered delivery is a natural concept that has value >>beyond any single ULP. > > > I don't think that the above functionality "rightfully > belongs to the transport layer (SCTP in this case)." To > me, the unordered delivery mechanism as specified in RFC > 2960 simply means that such data chunks can be delivered > in whatever order the receiver wants. This also > automatically means that the sender can send such chunks > in whatever order it wants if it deems necessary. For > example, an implementation can choose to place a smaller > unordered data chunk ahead in the send queue before a bigger > unordered data chunk. Assuming that the SSN is assigned > when data chunk is sent, to make the suggested change > to RFC 2960 to an implementation may mean more than what > has been discussed. And it is really a protocol change, > not just implementation's choice of how to generate > "arbitrary numbers" to be put in the SSN field of unordered > chunk as it actually places extra restrictions on how an > implementation handled such chunks as described above. > You make an excellent point.. for this very set of reasons one must not depend on being able to do priority of unordered data chunks as well. A implementation (as Brian mentioned his does) MAY prioritize un-ordered but it also MAY NOT... > The SSN in SCTP is designed to be used for order of > delivery by SCTP, that's why it is ignored for unordered > delivery. If an ULP wants to have ordered delivery, don't use > this feature of SCTP. If an ULP wants unordered delivery, but > it still wants to know the sender's sending order, just place > its own sequence number. Overloading the SSN in SCTP, even > if it is assigned by SCTP, not by ULP, is really a bad design > choice. > This brings up another point that I had not contemplated... if an implementation is assigning SSN's (as well as TSN's) at the last minute, the SSN assigned does NOT necessarily align with presentation order to SCTP. So by this reasoning it is really better if the ULP puts a SSN in its data as to how it presented the data to the SCTP stack... thus assuring the symantics it wants. I think you have convinced me it is better to let the ULP deal with it.. Oh, I do still think the CAPABILITIES indication may be a good thing though... R > Anyway, just my $0.02. BTW, I also cc the SCTP > implementors' list. I believe people there should > be aware of such things. I don't know why that list > was removed from the cc list... > > >>---- > > > > K. Poon. > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Feb 17 12:35:15 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 MAA26808 for ; Mon, 17 Feb 2003 12:35:14 -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 h1HHUYSQ001266 for ; Mon, 17 Feb 2003 09:30:34 -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 h1HHU8bw015677 for ; Mon, 17 Feb 2003 09:30:08 -0800 (PST) Received: from thebe.your-site.com (ns5.your-site.com [140.186.45.30] (may be forged)) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1HHUHQC004352 for ; Mon, 17 Feb 2003 09:30:20 -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 4E4F3245233; Mon, 17 Feb 2003 12:27:45 -0500 (EST) Date: Mon, 17 Feb 2003 11:28:57 -0600 From: Caitlin Bestler Subject: Re: [Tsvwg] A question of Un-Ordered SCTP To: Randall Stewart Cc: Kacheong Poon , tsvwg@ietf.org, sctp-impl@external.cisco.com X-Priority: 3 In-Reply-To: <3E510B7B.50803@stewart.chicago.il.us> 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/17/03, Randall Stewart wrote: > >This brings up another point that I had not >contemplated... if an implementation is assigning SSN's >(as well as TSN's) at the last minute, the SSN assigned >does NOT necessarily align with presentation order to >SCTP. So by this reasoning it is really better if the ULP >puts a SSN in its data as to how it presented the data to >the SCTP stack... thus assuring the symantics it wants. I >think you have convinced me it is better to let the ULP >deal with it.. > The essential characteristic of ULPs that would have used the sequenced unordered capability is that the order of presentation from the ULP has signifigance, but that data delivery should not be delayed at the receiving end to restore that original order, rather the information should be provided to the ULP to allow it to do so. Generally these applications would want their presentation order within a stream to match the actual transmit order. For streaming media applications this is crucial, it would be next to impossible for a sender transport re-ordering to be beneficial to the application. RDDP can be quite tolerant of order inversions between *some* Data Chunks (tagged ones between the same set of untagged messages), but complex "half-ordering" is pretty clearly ULP specific and not something that SCTP should be expected to support. So that leaves the same three options for comparison: 1) keep the sequence unordered capability, but clarify that in-stream order, as presented by the sending ULP, must be preserved by the sending SCTP layer. Any restoration of that order, however, is left to the receiving ULP. This contrasts with ordered delivery, where the receiving SCTP layer restores the order. The biggest hit here is that it is now clear that this method will not work for RDDP over unmodified SCTP stacks. If neither the TSN or SSN can be relied upon to reflect the sending RDDPs ordering critical RDDP ordering rules cannot be properly enforced. 2) ULP labeling of DDP stream ordering combined with unordered delivery. The receiving DDP layer is solely responsible for restoration of order. This actually isn't that bad for RDDP. For streaming media applications, particularly over partially reliable SCTP, it has the negative effect of failing to constrain the sending SCTP layer to send the data chunks in the order presented. 3) Unordered delivery of ordered data streams. A purely local interface option allows the receiving ULP to specify whether it wants SCTP to hold data chunks until they can be delivered in order, or to deliver them early and merely indicate the order they should have been in. This approach has some very nice features, but has very serious performance impilcations if RDDP is implemented on top of an unmodified SCTP receiver. If several implementers believe that the third option is a relatively minor fix, then I believe that it would be an adequate solution for both RDDP and streaming media ULPs. Otherwise the second option looks like the best approach. Caitlin Bestler http://asomi.com/CaitlinBestler/ From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Feb 18 04:18:32 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 EAA23021 for ; Tue, 18 Feb 2003 04:18:31 -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 h1I97fB6029282 for ; Tue, 18 Feb 2003 01:07:41 -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 h1I97p2n014101 for ; Tue, 18 Feb 2003 01:07:51 -0800 (PST) Received: from ims21.stu.nus.edu.sg (ims21.stu.nus.edu.sg [137.132.14.228]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1I96DbJ028057 for ; Tue, 18 Feb 2003 01:06:18 -0800 (PST) Received: from mbxsrv24.stu.nus.edu.sg ([137.132.14.234]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Feb 2003 17:05:37 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D72C.E72688FC" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: Applications using SCTP multihoming Date: Tue, 18 Feb 2003 17:05:37 +0800 Message-ID: <720FB032F37C0D45A11085D881B03368A2B206@MBXSRV24.stu.nus.edu.sg> Thread-Topic: Applications using SCTP multihoming Thread-Index: AcLXLObKUr7QAtc7QLSNVimj1wwJlg== From: "Eng Se-Hsieng" To: , X-OriginalArrivalTime: 18 Feb 2003 09:05:37.0876 (UTC) FILETIME=[E74AB140:01C2D72C] This is a multi-part message in MIME format. ------_=_NextPart_001_01C2D72C.E72688FC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I'm running the 2.4.18 version of lksctp and wondering if I can make use of the mozilla or apache available on www.sctp.org which was written for BSD. Would anyone know of any applications (e.g. ftp, browser) written for lksctp which uses multihoming with failover successfully? Thank you. Regards, Se-Hsieng Singapore ------_=_NextPart_001_01C2D72C.E72688FC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Applications using SCTP multihoming

Dear all,

I'm running the 2.4.18 version of = lksctp and wondering if I can make use of the mozilla or apache = available on www.sctp.org = which was written for BSD.

Would anyone know of any applications = (e.g. ftp, browser) written for lksctp which uses multihoming with = failover successfully?

Thank you.

Regards,
Se-Hsieng
Singapore

------_=_NextPart_001_01C2D72C.E72688FC-- From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Tue Feb 18 07:45:06 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 HAA26743 for ; Tue, 18 Feb 2003 07:45:05 -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 h1ICd6sv022988; Tue, 18 Feb 2003 04:39:06 -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 ADM38370; Tue, 18 Feb 2003 04:39:19 -0800 (PST) Message-ID: <3E522976.90807@cisco.com> Date: Tue, 18 Feb 2003 06:39: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: Eng Se-Hsieng CC: sctp-impl@external.cisco.com, lksctp-developers@lists.sourceforge.net Subject: Re: Applications using SCTP multihoming References: <720FB032F37C0D45A11085D881B03368A2B206@MBXSRV24.stu.nus.edu.sg> Content-Type: multipart/related; boundary="------------010209020706050409000504" --------------010209020706050409000504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eng Se-Hsieng wrote: > Dear all, > > I'm running the 2.4.18 version of lksctp and wondering if I can make > use of the mozilla or apache available on _www.sctp.org_ > which was written for BSD. > > Would anyone know of any applications (e.g. ftp, browser) written for > lksctp which uses multihoming with failover successfully? > > Thank you. > > Regards, > Se-Hsieng > Singapore > Se-Hsieng: I can't say for sure if it will work, having not tested it :> It really depends on if lksctp implemented the TCP model API. This is required, since the mozilla on www.sctp.org just changes a few things (aka the protocol type) in all the socket calls. Maybe Jon can say if the TCP model is there.. Regards R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) --------------010209020706050409000504-- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Feb 18 09:47:30 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 JAA29109 for ; Tue, 18 Feb 2003 09:47:28 -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 h1IEgoSQ014188 for ; Tue, 18 Feb 2003 06:42:50 -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 h1IEgnKa011578 for ; Tue, 18 Feb 2003 06:42:49 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1IEfEbJ004814 for ; Tue, 18 Feb 2003 06:41:15 -0800 (PST) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1IEaFEs131396; Tue, 18 Feb 2003 09:36:15 -0500 Received: from us.ibm.com ([9.53.216.106]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1IEaDAq030682; Tue, 18 Feb 2003 09:36:13 -0500 Message-ID: <3E52446F.6080802@us.ibm.com> Date: Tue, 18 Feb 2003 08:34:23 -0600 From: Jon Grimm Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: Eng Se-Hsieng , sctp-impl@external.cisco.com, lksctp-developers@lists.sourceforge.net Subject: Re: [Lksctp-developers] Re: Applications using SCTP multihoming References: <720FB032F37C0D45A11085D881B03368A2B206@MBXSRV24.stu.nus.edu.sg> <3E522976.90807@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Maybe Jon can say if the TCP model is there.. > Hi Eng (& Randy) Nope, lksctp doesn't yet have TCP-style ... however I anticipate starting this within the month. BTW, the 2.4.18 lksctp is far, far out of date and not supported. If you want to play with failover, you should be able to use sctp_darn or sctp_test which are in the sctp-tools tarball. Best Regards, Jon From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Wed Feb 19 07:20:59 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 HAA21175 for ; Wed, 19 Feb 2003 07:20:57 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1JCFkB6017618 for ; Wed, 19 Feb 2003 04:15:46 -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 h1JCFTG6014444 for ; Wed, 19 Feb 2003 04:15:29 -0800 (PST) Received: from ims21.stu.nus.edu.sg (ims21.stu.nus.edu.sg [137.132.14.228]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1JCFfXD010861 for ; Wed, 19 Feb 2003 04:15:44 -0800 (PST) Received: from mbxsrv24.stu.nus.edu.sg ([137.132.14.234]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.5329); Wed, 19 Feb 2003 20:13:35 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [Lksctp-developers] Re: Applications using SCTP multihoming X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 19 Feb 2003 20:13:35 +0800 Message-ID: <720FB032F37C0D45A11085D881B033684CBC75@MBXSRV24.stu.nus.edu.sg> Thread-Topic: [Lksctp-developers] Re: Applications using SCTP multihoming Thread-Index: AcLXXCGg5RckiOAyRFGtqiMhIU8TFAAr90XM From: "Eng Se-Hsieng" To: "Jon Grimm" , "Randall Stewart (cisco)" Cc: , X-OriginalArrivalTime: 19 Feb 2003 12:13:35.0818 (UTC) FILETIME=[53E1D2A0:01C2D810] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA21175 > If you want to play with failover, you should be able to use sctp_darn or sctp_test which are in the sctp-tools tarball. Not all my network interfaces were accessible using sctp_darn. My Toshiba satellite 4030CDT has one wired LAN connection (eth0) and one wireless LAN (Cisco Aironet 350:eth1). In one shell, I typed 'sctp_darn -H 0 -P 250 -l' and in another I entered 'sctp_darn -H 0 -P 260 -h X.X.X.X -p 250 -s', replacing X.X.X.X with the IP addresses of localhost, eth0 and eth1 successively. The listening side received messages sent to localhost and WLAN successfully and 6 SCTP frames were generated each time in ethereal. However, no message was received when the remote host was set to wired LAN but Ethereal shows an INIT from the WLAN interface to the wired LAN interface. If I bind the multiple addresses manually with the -B option, I can only receive messages sent to the WLAN interface. 1. Was my usage of sctp_darn correct for a multihoming case? 2. For failover, I disconnected the WLAN card. The messages did not arrive on the wired LAN interface. 3. Ethereal hangs after capture or shuts itself down while testing the above. I would be most grateful for any suggestions. > BTW, the 2.4.18 lksctp is far, far out of date and not supported. It is apparently not trivial to upgrade from Redhat 7.3 2.4.18 to 2.5.59. While I understand that this would allow me to keep in sync with lksctp, I apparently need to upgrade a lot of software (compilers, libs,etc.). Could someone kindly point me to an appropriate resource or offer more detailed instructions please? Thank you. Eng Se-Hsieng -----Original Message----- From: Jon Grimm [mailto:jgrimm2@us.ibm.com] Sent: Tue 2/18/2003 10:34 PM To: Randall Stewart (cisco) Cc: Eng Se-Hsieng; sctp-impl@external.cisco.com; lksctp-developers@lists.sourceforge.net Subject: Re: [Lksctp-developers] Re: Applications using SCTP multihoming > Maybe Jon can say if the TCP model is there.. > Hi Eng (& Randy) Nope, lksctp doesn't yet have TCP-style ... however I anticipate starting this within the month. BTW, the 2.4.18 lksctp is far, far out of date and not supported. If you want to play with failover, you should be able to use sctp_darn or sctp_test which are in the sctp-tools tarball. Best Regards, Jon From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Wed Feb 19 09:43:39 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 JAA26205 for ; Wed, 19 Feb 2003 09:43:38 -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 h1JEcZB6025313 for ; Wed, 19 Feb 2003 06:38: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 h1JEcjmn025267 for ; Wed, 19 Feb 2003 06:38:45 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1JEbAsf022149 for ; Wed, 19 Feb 2003 06:37:11 -0800 (PST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1JEWDl3061352; Wed, 19 Feb 2003 09:32:13 -0500 Received: from us.ibm.com (grimm.austin.ibm.com [9.53.216.106] (may be forged)) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1JEWAIc010940; Wed, 19 Feb 2003 09:32:10 -0500 Message-ID: <3E5394FB.4080200@us.ibm.com> Date: Wed, 19 Feb 2003 08:30:19 -0600 From: Jon Grimm Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eng Se-Hsieng CC: "Randall Stewart (cisco)" , sctp-impl@external.cisco.com, lksctp-developers@lists.sourceforge.net Subject: Re: [Lksctp-developers] Re: Applications using SCTP multihoming References: <720FB032F37C0D45A11085D881B033684CBC75@MBXSRV24.stu.nus.edu.sg> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Eng, Lets move this discussion to lksctp-developers. Thanks, jon Eng Se-Hsieng wrote: >>If you want to play with failover, you should be able to use sctp_darn > > or sctp_test which are in the sctp-tools tarball. > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Feb 19 10:59:40 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 KAA29675 for ; Wed, 19 Feb 2003 10:59:39 -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 h1JFrqsv018406 for ; Wed, 19 Feb 2003 07:53:52 -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 h1JFs5Rt019485 for ; Wed, 19 Feb 2003 07:54:06 -0800 (PST) Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1JFrhGK010325 for ; Wed, 19 Feb 2003 07:53:50 -0800 (PST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id KAA27039; Wed, 19 Feb 2003 10:32:32 -0500 (EST) Message-ID: <3E53A390.4000509@ulticom.com> Date: Wed, 19 Feb 2003 10:32:32 -0500 From: David Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "K. Poon" CC: Randall Stewart , TSV WG list , SCTP Implementors Subject: Re: A question of Un-Ordered SCTP References: <20030217073910.21089.qmail@web41302.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit K. Poon wrote: > Is this similar in suggesting that since there are some bits > unused (wasted) in the TCP reserved bit field, we should allow > an app to set whatever value it likes in those bits? This may > sound a little bit extreme, but the idea is similar. I believe > if it is allowed, it will be a very bad precedence in SCTP > protocol development. We should not encourage app protocol > to "require" changes in SCTP simply because it is "convenient" > and "harmless" while it is just a simple matter to support the > changes in the app protocol itself. > > >>So what do all think of the idea? Good? Bad? > > > Just my $0.02, I think it is a bad idea... I agree with K. Poon 100%. Let the ULP put the sequence numbers of unordered data (and whatever else it wants) in its own headers. (K. Poon's stated it much more articulately, I must admit.) -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Feb 19 12:49:59 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 MAA03000 for ; Wed, 19 Feb 2003 12:49:56 -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 h1JHiWSQ022495 for ; Wed, 19 Feb 2003 09:44:32 -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 h1JHiWuN017391 for ; Wed, 19 Feb 2003 09:44:32 -0800 (PST) Received: from tokyo.ttech.de (ad96e068a.dsl.de.colt.net [217.110.6.138]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1JHgfsf018272 for ; Wed, 19 Feb 2003 09:42:43 -0800 (PST) Received: from testingtech.de (sofia.ttech.de [192.168.89.71]) by tokyo.ttech.de (8.11.6/8.11.6) with ESMTP id h1JHbIJ31763 for ; Wed, 19 Feb 2003 18:37:18 +0100 Message-ID: <3E53C0D7.1060907@testingtech.de> Date: Wed, 19 Feb 2003 18:37:27 +0100 From: Dirk Borowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: de-de, de MIME-Version: 1.0 To: sctp-impl@external.cisco.com Subject: Cookie generation in SCTP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, I have some questions about SCTP cookies. Is it possible to get a detailed description about how a cookie for SCTP looks like or an example cookie to get a feeling how to implement one ? All we found in the standard is that some steps SHOULD be taken to generate the State Cookie but there is no actual format described. It is my guts feeling, that the actual format of the cookie parameter is implementation depended. Or is there a common format that has been agreed upon (hashing function, etc)? If yes, are there already any implementations or existing java classes which provides cookie generation ? Thanks in advance for your answers Nice regards Dirk From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Feb 19 13:35:00 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 NAA04296 for ; Wed, 19 Feb 2003 13:34:53 -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 h1JIUKSQ025043 for ; Wed, 19 Feb 2003 10:30: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 h1JITqmA010076 for ; Wed, 19 Feb 2003 10:29:52 -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 h1JIRXsf001099 for ; Wed, 19 Feb 2003 10:27:34 -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 h1JI9Xm23160 for ; Wed, 19 Feb 2003 20:09:33 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Feb 2003 20:06:34 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 20:06:34 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 20:06:34 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 20:06:33 +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: Cookie generation in SCTP Date: Wed, 19 Feb 2003 20:06:33 +0200 Message-ID: Thread-Topic: Cookie generation in SCTP Thread-Index: AcLYQBc3U5ad6l/iToSJL1JJVaS66AAAN99g From: To: , X-OriginalArrivalTime: 19 Feb 2003 18:06:33.0762 (UTC) FILETIME=[A2EBA020:01C2D841] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA04296 Hi Dirk! See my comments inline... > Dear all, > > I have some questions about SCTP cookies. > > Is it possible to get a detailed description about how a > cookie for SCTP > looks like or an example cookie to get a feeling how to > implement one ? > > All we found in the standard is that some steps SHOULD be taken to > generate the State Cookie but there is no actual format described. > > It is my guts feeling, that the actual format of the cookie > parameter is > implementation depended. Or is there a common format that has been > agreed upon (hashing function, etc)? You are right... RFC 2960 shows some guidelines about how the cookie should be constructed. However, as it is the sender of the cookie itself the only one that should pay attention to this field (upon receipt of the COOKIE ECHO), its design is completely up to the sender... You can use any hash function you want to generate it. You can even generate a dummy cookie, or you don't even have to check it if you don't want. But, of course, the more care you put in the construction and verification of the cookie, the more strong against attacks your implementation will be. I use what it is stated in the RFC, and I guess that most of us do the same. > If yes, are there already any implementations or existing > java classes > which provides cookie generation ? I don't know about this, but for sure there will be some C functions available in the open source implementations. BR Iván Arias Rodríguez > Thanks in advance for your answers > > Nice regards > Dirk > > From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Feb 19 14:36:05 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 OAA06248 for ; Wed, 19 Feb 2003 14:36: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-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1JJVfSQ007655; Wed, 19 Feb 2003 11:31: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 ADO12223; Wed, 19 Feb 2003 11:31:41 -0800 (PST) Message-ID: <3E53DB9C.8070007@cisco.com> Date: Wed, 19 Feb 2003 13:31:40 -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, borowski@testingtech.de CC: sctp-impl@external.cisco.com Subject: Re: Cookie generation in SCTP References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit A comment or two inline :> Ivan.Arias-Rodriguez@nokia.com wrote: > Hi Dirk! > > See my comments inline... > > > >>Dear all, >> >>I have some questions about SCTP cookies. >> >>Is it possible to get a detailed description about how a >>cookie for SCTP >>looks like or an example cookie to get a feeling how to >>implement one ? >> >>All we found in the standard is that some steps SHOULD be taken to >>generate the State Cookie but there is no actual format described. >> >>It is my guts feeling, that the actual format of the cookie >>parameter is >>implementation depended. Or is there a common format that has been >>agreed upon (hashing function, etc)? >> >> > > You are right... RFC 2960 shows some guidelines about how the cookie should be constructed. However, as it is the sender of the cookie itself the only one that should pay attention to this field (upon receipt of the COOKIE ECHO), its design is completely up to the sender... > > You can use any hash function you want to generate it. You can even generate a dummy cookie, or you don't even have to check it if you don't want. But, of course, the more care you put in the construction and verification of the cookie, the more strong against attacks your implementation will be. > > I use what it is stated in the RFC, and I guess that most of us do the same. > Yeah, I think most of us are either using MD5 or SHA-1. I use SHA-1 by default for my signature.. a bit stronger but more CPU required :-0 thats why a compile switch can have it use MD5 :-> It is very very un-wise to not have some sort of hash in the cookie.. not saying you can't do it this way.. especially if you are worried about a DOS attack against your CPU... This is why we tried to be vague here... It depends on what threat you are most worried about... memory or CPU... > > > >>If yes, are there already any implementations or existing >>java classes >>which provides cookie generation ? >> >> > > I don't know about this, but for sure there will be some C functions available in the open source implementations. > You can find an example of the SHA-1 type cookie generation in the BSD code inside the kame software http://www.kame.net In particular in sctp_output.c of this code you will find a "sctp_add_cookie()" function. This will call the fnc sctp_hash_disgest_m() which builds the signature over the cookie based on the compile switch MD5 or SHA-1 I am sure you can also find in the lksctp version a hashing algorithm as well.. Hope that helps... > > BR Iván Arias Rodríguez > > > >>Thanks in advance for your answers >> >>Nice regards >>Dirk >> >> >> > > > > -- 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 Wed Feb 19 16:26: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 QAA09180 for ; Wed, 19 Feb 2003 16:26:39 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1JLM4B6000098 for ; Wed, 19 Feb 2003 13:22:04 -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 h1JLLkaZ019049 for ; Wed, 19 Feb 2003 13:21:46 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id h1JLMClJ016793 for ; Wed, 19 Feb 2003 13:22:16 -0800 (PST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1JLFI5X070252; Wed, 19 Feb 2003 16:15:18 -0500 Received: from us.ibm.com ([9.53.216.106]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1JLFEIc098758; Wed, 19 Feb 2003 16:15:15 -0500 Message-ID: <3E53F374.2040903@us.ibm.com> Date: Wed, 19 Feb 2003 15:13:24 -0600 From: Jon Grimm Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Randall Stewart , borowski@testingtech.de, sctp-impl@external.cisco.com Subject: Re: Cookie generation in SCTP References: <3E53DB9C.8070007@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: > > I am sure you can also find in the lksctp version a hashing > algorithm as well.. > Yep, lksctp use SHA-1 (the hash code has its heritage in Randy's user-level impl. IIRC). A warning..our COOKIE is pretty huge & has lots of redundant fields. So as a counter-plug, Randy and Qiaobing's book goes into interesting tidbits to put in one's cookie and why one would need them. Best Regards, Jon Grimm From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Wed Feb 19 16:41:47 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 QAA09713 for ; Wed, 19 Feb 2003 16:41:46 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1JLbEB6024174 for ; Wed, 19 Feb 2003 13:37:15 -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 h1JLavL4000288 for ; Wed, 19 Feb 2003 13:36:57 -0800 (PST) Received: from stewart.chicago.il.us ([67.38.193.238]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id h1JLbJlJ022858 for ; Wed, 19 Feb 2003 13:37:24 -0800 (PST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1JLUGaX001286; Wed, 19 Feb 2003 15:30:16 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E53F768.9040706@stewart.chicago.il.us> Date: Wed, 19 Feb 2003 15:30:16 -0600 From: Randall Stewart 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: Jon Grimm CC: borowski@testingtech.de, sctp-impl@external.cisco.com Subject: Re: Cookie generation in SCTP References: <3E53DB9C.8070007@cisco.com> <3E53F374.2040903@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon Grimm wrote: > Randall Stewart (cisco) wrote: > >> >> I am sure you can also find in the lksctp version a hashing >> algorithm as well.. >> > > Yep, lksctp use SHA-1 (the hash code has its heritage in Randy's > user-level impl. IIRC). A warning..our COOKIE is pretty huge & has lots > of redundant fields. So as a counter-plug, Randy and Qiaobing's book > goes into interesting tidbits to put in one's cookie and why one would > need them. > > Best Regards, > Jon Grimm > > > Thanks for the plug :> And I think one would find the kame implementation and the book have about the same cookie stuff as described .. (not that I am saying not to buy the book mind you :>) we may be a bit bigger (we have a bunch of scoping stuff we also put in) but in general we have smaller than 200 byte (or so) cookies... R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Thu Feb 20 05:28:32 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 FAA06597 for ; Thu, 20 Feb 2003 05:28:31 -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 h1KAJlap002957 for ; Thu, 20 Feb 2003 02:19:47 -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 h1KAJkDn012628 for ; Thu, 20 Feb 2003 02:19:46 -0800 (PST) Received: from mailrelay03.wind.it (mailrelay03.wind.it [212.141.48.56]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1KAHtsf020791 for ; Thu, 20 Feb 2003 02:18:10 -0800 (PST) Received: from mailrelay03.wind.it ([212.141.48.56]) by mailrelay03.wind.it with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.52) id 1VD48PJ3; Thu, 20 Feb 2003 11:12:23 +0100 Received: by wexrm3co.wind with Internet Mail Service (5.5.2653.19) id <1VDG3RZ4>; Thu, 20 Feb 2003 11:15:18 +0100 Message-ID: From: Troiano Marco To: "'sctp-impl@external.cisco.com'" Subject: sctp Date: Thu, 20 Feb 2003 11:15:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D8C8.D891202A" ------_=_NextPart_001_01C2D8C8.D891202A Content-Type: text/plain; charset="iso-8859-1" Hi ALL, I am working on SCTP and I would like to ask you what are possible values for "cookie information" and "heartbeat information" in an SCTP control packet?What is the typical length of these fields? Thanks in advance Marco ------_=_NextPart_001_01C2D8C8.D891202A Content-Type: text/html; charset="iso-8859-1" sctp

Hi ALL,
I  am  working  on  SCTP and I would like to ask you what are possible
values for "cookie information" and "heartbeat information" in an SCTP
control packet?What is the typical length of these fields?
Thanks in advance
Marco



------_=_NextPart_001_01C2D8C8.D891202A-- --------------InterScan_NT_MIME_Boundary-- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Feb 20 10:29:18 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 KAA17881 for ; Thu, 20 Feb 2003 10:29:17 -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 h1KFN0SQ027074 for ; Thu, 20 Feb 2003 07:23:00 -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 h1KFMVhd024140 for ; Thu, 20 Feb 2003 07:22:31 -0800 (PST) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1KFKuj5007578 for ; Thu, 20 Feb 2003 07:20:58 -0800 (PST) Received: from horus.imag.fr (horus.imag.fr [129.88.38.1]) by imag.imag.fr (8.12.7/8.12.7) with ESMTP id h1KEivZc020535 for ; Thu, 20 Feb 2003 15:44:57 +0100 (CET) Received: from borneo (borneo.imag.fr [129.88.38.174]) by horus.imag.fr (8.11.6/8.11.6/Imag.pm.V2) with ESMTP id h1KEiuN23409 for ; Thu, 20 Feb 2003 15:44:57 +0100 (MET) Date: Thu, 20 Feb 2003 15:44:46 +0100 From: Pawel Hadam X-Mailer: The Bat! (v1.60q) Reply-To: Pawel Hadam Organization: LSR-IMAG X-Priority: 3 (Normal) Message-ID: <11922052519.20030220154446@imag.fr> To: "SCTP @ Cisco" Subject: Source Address Selection MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all In [RFC2960, 6.4] I may read: "By default, an endpoint SHOULD always transmit to the primary path, unless the SCTP user explicitly specifies the destination transport address (AND POSSIBLY SOURCE TRANSPORT ADDRESS) to use." And later in [RFC2960, 6.4.1]: "Note: Rules for picking the most divergent source-destination pair are an implementation decision and is not specified within this document." So I have the following questions: - are there any ideas/proposals about the SOURCE network address selection? - are there any work in progress about it? As I can see now, the SOURCE network address for a packet is chosen by the routing system on the base of the destination address chosen by SCTP. But I would like to see some solution that will let me choose "manualy" the SOURCE network address for each outgoing packet. And, I would like to have some rules to decide about the SOURCE network address. Is anobody involved in some work like this, or is it still an untouched area? -- Best regards Pawel Hadam From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Feb 20 11:07:07 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 LAA19337 for ; Thu, 20 Feb 2003 11:07:06 -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 h1KG29SQ023148; Thu, 20 Feb 2003 08:02:10 -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 ADP18467; Thu, 20 Feb 2003 08:02:08 -0800 (PST) Message-ID: <3E54FBFE.2090205@cisco.com> Date: Thu, 20 Feb 2003 10:02:06 -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: Pawel Hadam CC: "SCTP @ Cisco" Subject: Re: Source Address Selection References: <11922052519.20030220154446@imag.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pawel: Comments below.. Pawel Hadam wrote: >Hi all > >In [RFC2960, 6.4] I may read: >"By default, an endpoint SHOULD always transmit to the primary path, >unless the SCTP user explicitly specifies the destination transport >address (AND POSSIBLY SOURCE TRANSPORT ADDRESS) to use." > >And later in [RFC2960, 6.4.1]: >"Note: Rules for picking the most divergent source-destination pair >are an implementation decision and is not specified within this >document." > >So I have the following questions: >- are there any ideas/proposals about the SOURCE network address selection? >- are there any work in progress about it? > >As I can see now, the SOURCE network address for a packet is chosen >by the routing system on the base of the destination address chosen >by SCTP. But I would like to see some solution that will let me choose "manualy" the SOURCE network address for each outgoing >packet. And, I would like to have some rules to decide about the >SOURCE network address. > >Is anobody involved in some work like this, or is it still an untouched >area? > > Yes, there is some work going on in this area. I recently have had contact with Katsuyoshi Iida and Toshiyuki Kubo Kubo-san as just finished his masters thesis covering some of this area (hopefully he will make his findings public soon). Also I believe the draft on multi-homing that Lode Coene is editor of also discusses this. I also put a solution to this (somewhat) in the kame/bsd implementation when RADIX_MPATH and SCTP_ALTERNATE_ROUTE is enabled. First of all there are a general set of rules one should apply when possible for source address selection... 1) Always, if possible, use the source address of the interface you will emit the packet on. This means that routing becomes a big factor... This is why I put the options in the bsd implementation.. one must have the ability to have more than one route to a peer in order to have different interfaces. 2) If you can't do <1> then you need to pick a reasonable alternate src address with which to use (possibly rotating amongst the available ones in some cases). 3) One must also take into account that most endhosts will be connected via one (or more) ISP's which may well do address filtering to protect against DOS attacks.. this means that if you can't use a source address that corresponds with the ISP's idea of your address assigned your packet will be filtered.. Example. I have two ISP's A and B. and Two address ISP-A-IP and ISP-B-IP. If I send a packet to ISP-A default router address but use source address ISP-B-IP then chances are ISP-A will drop the packet. 4) In some cases (especially v6) one may have multiple sources that are valid to use in sending to the peer. In such a case one must choose a source using a scope that will most likely assure the peer can reach you, aka you must choose the same or higher scope of the destination address... some of this is discussed in the v6 and v4 scoping drafts... Most kernel implementations DO source address selection.. I know ours does.. no matter if the RADIX_MPATH/SCTP_ALTERNATE_ROUTE is enabled. In fact for IPv6 you MUST do this (with kame) since you can't let the ip6_output choose a source address... There are still areas to look at for sure.. but some of what I have mentioned will be a good start for your investagation.. 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-1.cisco.com Mon Feb 24 09:29:05 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 JAA15247 for ; Mon, 24 Feb 2003 09:28:48 -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 h1OEB4SQ017691 for ; Mon, 24 Feb 2003 06:11:09 -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 h1OEAxo6028779 for ; Mon, 24 Feb 2003 06:11:02 -0800 (PST) Received: from stewart.chicago.il.us ([67.38.193.238]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1OEA4VD021913 for ; Mon, 24 Feb 2003 06:10:28 -0800 (PST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1OE5XDY007597 for ; Mon, 24 Feb 2003 08:05:34 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E5A26AD.8090007@stewart.chicago.il.us> Date: Mon, 24 Feb 2003 08:05:33 -0600 From: Randall Stewart 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 Implementors Subject: short time on this one.. Content-Type: multipart/mixed; boundary="------------030607060300010001060302" This is a multi-part message in MIME format. --------------030607060300010001060302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all. Sorry about being late.. just a short time on this one.. a few minor fixes... and Armando's clearificaqtion on fast retransmit.. Comments no later than Tommorrow night please.. Thanks R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) --------------030607060300010001060302 Content-Type: text/plain; name="draft-ietf-tsvwg-sctpimpguide-08.txt" Content-Disposition: inline; filename="draft-ietf-tsvwg-sctpimpguide-08.txt" Content-Transfer-Encoding: 7bit Network Working Group R. Stewart Internet-Draft Cisco Systems, Inc. Expires: August 30, 2003 L. Ong Ciena Systems I. Arias-Rodriguez Nokia Research Center K. Poon P. Conrad Temple University A. Caro University of Delaware M. Tuexen Siemens AG March 2003 Stream Control Transmission Protocol (SCTP) Implementer's Guide draft-ietf-tsvwg-sctpimpguide-08.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Stewart, et al. Expires August 30, 2003 [Page 1] Internet-Draft SCTP Implementer's Guide March 2003 This document contains a compilation of all defects found up until the publishing of this document for the Stream Control Transmission Protocol (SCTP) RFC2960 [4]. 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 [4] and text within this document supersedes the text found in RFC2960 [4]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 2. Corrections to RFC2960 . . . . . . . . . . . . . . . . . . 6 2.1 Incorrect error type during chunk processing. . . . . . . 6 2.1.1 Description of the problem . . . . . . . . . . . . . . . . 6 2.1.2 Text changes to the document . . . . . . . . . . . . . . . 6 2.1.3 Solution description . . . . . . . . . . . . . . . . . . . 6 2.2 Parameter processing issue . . . . . . . . . . . . . . . . 6 2.2.1 Description of the problem . . . . . . . . . . . . . . . . 6 2.2.2 Text changes to the document . . . . . . . . . . . . . . . 7 2.2.3 Solution description . . . . . . . . . . . . . . . . . . . 7 2.3 Padding issues . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1 Description of the problem . . . . . . . . . . . . . . . . 7 2.3.2 Text changes to the document . . . . . . . . . . . . . . . 7 2.3.3 Solution description . . . . . . . . . . . . . . . . . . . 9 2.4 Parameter types across all chunk types . . . . . . . . . . 9 2.4.1 Description of the problem . . . . . . . . . . . . . . . . 9 2.4.2 Text changes to the document . . . . . . . . . . . . . . . 9 2.4.3 Solution description . . . . . . . . . . . . . . . . . . . 10 2.5 Stream parameter clarification . . . . . . . . . . . . . . 11 2.5.1 Description of the problem . . . . . . . . . . . . . . . . 11 2.5.2 Text changes to the document . . . . . . . . . . . . . . . 11 2.5.3 Solution description . . . . . . . . . . . . . . . . . . . 11 2.6 Restarting association security issue . . . . . . . . . . 12 2.6.1 Description of the problem . . . . . . . . . . . . . . . . 12 2.6.2 Text changes to the document . . . . . . . . . . . . . . . 12 2.6.3 Solution description . . . . . . . . . . . . . . . . . . . 16 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes . . . . . 16 2.7.1 Description of the problem . . . . . . . . . . . . . . . . 16 2.7.2 Text changes to the document . . . . . . . . . . . . . . . 17 2.7.3 Solution description . . . . . . . . . . . . . . . . . . . 17 2.8 Issues with Fast Retransmit . . . . . . . . . . . . . . . 17 2.8.1 Description of the problem . . . . . . . . . . . . . . . . 17 2.8.2 Text changes to the document . . . . . . . . . . . . . . . 17 2.8.3 Solution description . . . . . . . . . . . . . . . . . . . 20 2.9 Missing statement about partial_bytes_acked update . . . . 21 Stewart, et al. Expires August 30, 2003 [Page 2] Internet-Draft SCTP Implementer's Guide March 2003 2.9.1 Description of the problem . . . . . . . . . . . . . . . . 21 2.9.2 Text changes to the document . . . . . . . . . . . . . . . 21 2.9.3 Solution description . . . . . . . . . . . . . . . . . . . 22 2.10 Issues with Heartbeating and failure detection . . . . . . 22 2.10.1 Description of the problem . . . . . . . . . . . . . . . . 22 2.10.2 Text changes to the document . . . . . . . . . . . . . . . 22 2.10.3 Solution description . . . . . . . . . . . . . . . . . . . 25 2.11 Security interactions with firewalls . . . . . . . . . . . 25 2.11.1 Description of the problem . . . . . . . . . . . . . . . . 25 2.11.2 Text changes to the document . . . . . . . . . . . . . . . 25 2.11.3 Solution description . . . . . . . . . . . . . . . . . . . 27 2.12 Shutdown ambiguity . . . . . . . . . . . . . . . . . . . . 27 2.12.1 Description of the problem . . . . . . . . . . . . . . . . 27 2.12.2 Text changes to the document . . . . . . . . . . . . . . . 27 2.12.3 Solution description . . . . . . . . . . . . . . . . . . . 29 2.13 Inconsistency in ABORT processing . . . . . . . . . . . . 29 2.13.1 Description of the problem . . . . . . . . . . . . . . . . 29 2.13.2 Text changes to the document . . . . . . . . . . . . . . . 29 2.13.3 Solution description . . . . . . . . . . . . . . . . . . . 30 2.14 Cwnd gated by its full use . . . . . . . . . . . . . . . . 30 2.14.1 Description of the problem . . . . . . . . . . . . . . . . 30 2.14.2 Text changes to the document . . . . . . . . . . . . . . . 31 2.14.3 Solution description . . . . . . . . . . . . . . . . . . . 33 2.15 Window probes in SCTP . . . . . . . . . . . . . . . . . . 33 2.15.1 Description of the problem . . . . . . . . . . . . . . . . 34 2.15.2 Text changes to the document . . . . . . . . . . . . . . . 34 2.15.3 Solution description . . . . . . . . . . . . . . . . . . . 35 2.16 Fragmentation and Path MTU issues . . . . . . . . . . . . 36 2.16.1 Description of the problem . . . . . . . . . . . . . . . . 36 2.16.2 Text changes to the document . . . . . . . . . . . . . . . 36 2.16.3 Solution description . . . . . . . . . . . . . . . . . . . 37 2.17 Initial value of the cumulative TSN Ack . . . . . . . . . 37 2.17.1 Description of the problem . . . . . . . . . . . . . . . . 37 2.17.2 Text changes to the document . . . . . . . . . . . . . . . 37 2.17.3 Solution description . . . . . . . . . . . . . . . . . . . 38 2.18 Handling of address parameters within the INIT or INIT-ACK . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.18.1 Description of the problem . . . . . . . . . . . . . . . . 38 2.18.2 Text changes to the document . . . . . . . . . . . . . . . 38 2.18.3 Solution description . . . . . . . . . . . . . . . . . . . 39 2.19 Handling of stream shortages . . . . . . . . . . . . . . . 39 2.19.1 Description of the problem . . . . . . . . . . . . . . . . 40 2.19.2 Text changes to the document . . . . . . . . . . . . . . . 40 2.19.3 Solution description . . . . . . . . . . . . . . . . . . . 41 2.20 Indefinite postponement . . . . . . . . . . . . . . . . . 41 2.20.1 Description of the problem . . . . . . . . . . . . . . . . 41 2.20.2 Text changes to the document . . . . . . . . . . . . . . . 41 2.20.3 Solution description . . . . . . . . . . . . . . . . . . . 42 Stewart, et al. Expires August 30, 2003 [Page 3] Internet-Draft SCTP Implementer's Guide March 2003 2.21 User initiated abort of an association . . . . . . . . . . 42 2.21.1 Description of the problem . . . . . . . . . . . . . . . . 42 2.21.2 Text changes to the document . . . . . . . . . . . . . . . 43 2.21.3 Solution description . . . . . . . . . . . . . . . . . . . 48 2.22 Handling of invalid Initiate Tag of INIT-ACK . . . . . . . 48 2.22.1 Description of the problem . . . . . . . . . . . . . . . . 48 2.22.2 Text changes to the document . . . . . . . . . . . . . . . 48 2.22.3 Solution description . . . . . . . . . . . . . . . . . . . 49 2.23 ABORT sending in response to an INIT . . . . . . . . . . . 49 2.23.1 Description of the problem . . . . . . . . . . . . . . . . 50 2.23.2 Text changes to the document . . . . . . . . . . . . . . . 50 2.23.3 Solution description . . . . . . . . . . . . . . . . . . . 50 2.24 Stream Sequence Number (SSN) Initialization . . . . . . . 50 2.24.1 Description of the problem . . . . . . . . . . . . . . . . 50 2.24.2 Text changes to the document . . . . . . . . . . . . . . . 51 2.24.3 Solution description . . . . . . . . . . . . . . . . . . . 51 2.25 SACK packet format . . . . . . . . . . . . . . . . . . . . 51 2.25.1 Description of the problem . . . . . . . . . . . . . . . . 51 2.25.2 Text changes to the document . . . . . . . . . . . . . . . 52 2.25.3 Solution description . . . . . . . . . . . . . . . . . . . 52 2.26 Protocol Violation Error Cause . . . . . . . . . . . . . . 52 2.26.1 Description of the problem . . . . . . . . . . . . . . . . 52 2.26.2 Text changes to the document . . . . . . . . . . . . . . . 52 2.26.3 Solution description . . . . . . . . . . . . . . . . . . . 54 2.27 Reporting of Unrecognized Parameters . . . . . . . . . . . 54 2.27.1 Description of the problem . . . . . . . . . . . . . . . . 54 2.27.2 Text changes to the document . . . . . . . . . . . . . . . 55 2.27.3 Solution description . . . . . . . . . . . . . . . . . . . 56 2.28 Handling of IP Address Parameters . . . . . . . . . . . . 56 2.28.1 Description of the problem . . . . . . . . . . . . . . . . 56 2.28.2 Text changes to the document . . . . . . . . . . . . . . . 57 2.28.3 Solution description . . . . . . . . . . . . . . . . . . . 57 2.29 Handling of COOKIE ECHO chunks when a TCB exists . . . . 57 2.29.1 Description of the problem . . . . . . . . . . . . . . . . 57 2.29.2 Text changes to the document . . . . . . . . . . . . . . . 58 2.29.3 Solution description . . . . . . . . . . . . . . . . . . . 58 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 59 References . . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 60 Intellectual Property and Copyright Statements . . . . . . 63 Stewart, et al. Expires August 30, 2003 [Page 4] Internet-Draft SCTP Implementer's Guide March 2003 1. Introduction This document contains a compilation of all defects found up until the publishing of this document for the Stream Control Transmission Protocol (SCTP) RFC2960 [4]. 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 and text within this document, where noted, supersedes the text found in RFC2960 [4]. Each error will be detailed within this document in the form of: o The problem description, o The text quoted from RFC2960 [4], o The replacement text, o A description of the solution. 1.1 Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [2]. Stewart, et al. Expires August 30, 2003 [Page 5] Internet-Draft SCTP Implementer's Guide March 2003 2. Corrections to RFC2960 2.1 Incorrect error type during chunk processing. 2.1.1 Description of the problem A typo was discovered in RFC2960 [4] that incorrectly specifies an action to be taken when processing chunks of unknown identity. 2.1.2 Text changes to the document --------- Old text: (Section 3.2) --------- 01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK). --------- New text: (Section 3.2) --------- 01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized chunk in an 'Unrecognized Chunk Type'. 2.1.3 Solution description The receiver of an unrecognized Chunk should not send a 'parameter' error but instead the appropriate chunk error as described above. 2.2 Parameter processing issue 2.2.1 Description of the problem A typographical error was introduced through an improper cut and paste in the use of the upper two bits to describe proper handling of unknown parameters. Stewart, et al. Expires August 30, 2003 [Page 6] Internet-Draft SCTP Implementer's Guide March 2003 2.2.2 Text changes to the document --------- Old text: (Section 3.2.1) --------- 00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it. 01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK). --------- New text: (Section 3.2.1) --------- 00 - Stop processing this SCTP chunk and discard it, do not process any further parameters within this chunk. 01 - Stop processing this SCTP chunk and discard it, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK). 2.2.3 Solution description It was always the intent to stop processing at the level one was at in an unknown chunk or parameter with the upper bit set to 0. Thus if you are processing a chunk, you should drop the packet. If you are processing a parameter, you should drop the chunk. 2.3 Padding issues 2.3.1 Description of the problem A problem was found in that when a Chunk terminated in a TLV parameter. If this last TLV was not on a 32 bit boundary (as required), there was confusion as to if the last padding was included in the chunk length. 2.3.2 Text changes to the document --------- Old text: (Section 3.2) --------- Stewart, et al. Expires August 30, 2003 [Page 7] Internet-Draft SCTP Implementer's Guide March 2003 Chunk Length: 16 bits (unsigned integer) This value represents the size of the chunk in bytes including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any padding. Chunk Value: variable length The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type. The total length of a chunk (including Type, Length and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes and this padding is not included in the chunk length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes. --------- New text: (Section 3.2) --------- Chunk Length: 16 bits (unsigned integer) This value represents the size of the chunk in bytes including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any chunk padding. Chunks (including Type, Length and Value fields) are padded out by the sender with all zero bytes to be a multiple of 4 bytes long. This padding MUST NOT be more than 3 bytes in total. The Chunk Length value does not include terminating padding of the Chunk. However, it does include padding of any variable length parameter except the last parameter in the Chunk. The receiver MUST ignore the padding. Note: A robust implementation should accept the Chunk whether or not the final padding has been included in the Chunk Length. Chunk Value: variable length The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is Stewart, et al. Expires August 30, 2003 [Page 8] Internet-Draft SCTP Implementer's Guide March 2003 dependent on the Chunk Type. 2.3.3 Solution description The above text makes clear that the padding of the last parameter is not included in the Chunk Length field. It also clarifies that the padding of parameters that are not the last one must be counted in the Chunk Length field. 2.4 Parameter types across all chunk types 2.4.1 Description of the problem A problem was noted when multiple errors are needed to be sent regarding unknown or unrecognized parameters. Since often times the error type does not hold the chunk type field, it may become difficult to tell which error was associated with which chunk. 2.4.2 Text changes to the document --------- Old text: (Section 3.2.1) --------- The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 13.2. --------- New text: (Section 3.2.1) --------- The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 13.2. Note that a parameter type MUST be unique across all chunks. For example, the parameter type '5' is used to represent an IPv4 address (see section 3.3.2). The value '5' then is reserved across all chunks to represent an IPv4 address and MUST NOT be reused with a different meaning in any other chunk. --------- Old text: (Section 13.2) --------- 13.2 IETF-defined Chunk Parameter Extension The assignment of new chunk parameter type codes is done through an Stewart, et al. Expires August 30, 2003 [Page 9] Internet-Draft SCTP Implementer's Guide March 2003 IETF Consensus action as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information: a) Name of the parameter type. b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2.1. c) Detailed definition of each component of the parameter type. d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same chunk. --------- New text: (Section 13.2) --------- 13.2 IETF-defined Chunk Parameter Extension The assignment of new chunk parameter type codes is done through an IETF Consensus action as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information: a) Name of the parameter type. b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2.1. c) Detailed definition of each component of the parameter type. d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same chunk. e) Each parameter type MUST be unique across all chunks. 2.4.3 Solution description By having all parameters unique across all chunk assignments (the current assignment policy) no ambiguity exists as to what a parameter means based on context. The trade off for this is a smaller Stewart, et al. Expires August 30, 2003 [Page 10] Internet-Draft SCTP Implementer's Guide March 2003 parameter space i.e. 65,536 parameters versus 65,536 * Number-of-chunks. 2.5 Stream parameter clarification 2.5.1 Description of the problem A problem was found where the specification is unclear on the legality of an endpoint asking for more stream resources than were allowed in the MIS value of the INIT. In particular the value in the INIT ACK requested in its OS value was larger than the MIS value received in the INIT chunk. This behavior is illegal yet it was unspecified in RFC2960 [4] 2.5.2 Text changes to the document --------- Old text: (Section 3.3.3) --------- Number of Outbound Streams (OS): 16 bits (unsigned integer) Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST NOT be used. Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB. --------- New text: (Section 3.3.3) --------- Number of Outbound Streams (OS): 16 bits (unsigned integer) Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST NOT be used and the value MUST NOT be greater than the MIS value sent in the INIT chunk. Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB. 2.5.3 Solution description The change in wording, above, changes it so that a responder to an Stewart, et al. Expires August 30, 2003 [Page 11] Internet-Draft SCTP Implementer's Guide March 2003 INIT chunk does not specify more streams in its OS value than was represented to it in the MIS value i.e. its maximum. 2.6 Restarting association security issue 2.6.1 Description of the problem A security problem was found when a restart occurs. It is possible for an intruder to send an INIT to an endpoint of an existing association. In the INIT the intruder would list one or more of the current addresses of an association and its own. The normal restart procedures would then occur and the intruder would have hi-jacked an association. 2.6.2 Text changes to the document --------- Old text: (Section 3.3.10) --------- Cause Code Value Cause Code --------- ---------------- 1 Invalid Stream Identifier 2 Missing Mandatory Parameter 3 Stale Cookie Error 4 Out of Resource 5 Unresolvable Address 6 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 8 Unrecognized Parameters 9 No User Data 10 Cookie Received While Shutting Down Cause Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields Cause-specific Information: variable length This field carries the details of the error condition. Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3. Stewart, et al. Expires August 30, 2003 [Page 12] Internet-Draft SCTP Implementer's Guide March 2003 --------- New text: (Section 3.3.10) --------- Cause Code Value Cause Code --------- ---------------- 1 Invalid Stream Identifier 2 Missing Mandatory Parameter 3 Stale Cookie Error 4 Out of Resource 5 Unresolvable Address 6 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 8 Unrecognized Parameters 9 No User Data 10 Cookie Received While Shutting Down 11 Restart of an association with new addresses Cause Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields Cause-specific Information: variable length This field carries the details of the error condition. Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3. --------- New text: (Note no old text, new error cause added in section 3.3.10) --------- 3.3.10.11 Restart of an association with new addresses (11) Cause of error -------------- Restart of an association with new addresses: An INIT was received on an existing association. But the INIT added addresses to the association that were previously NOT part of the association. The New addresses are listed in the error code. This ERROR is normally sent as part of an ABORT refusing the INIT (see section 5.2). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=11 | Cause Length=Variable | Stewart, et al. Expires August 30, 2003 [Page 13] Internet-Draft SCTP Implementer's Guide March 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / New Address TLVs / \\ \\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------- Old text: (Section 5.2.1) --------- 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 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. --------- New text: (Section 5.2.1) --------- Upon receipt of an INIT in the COOKIE-WAIT 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). When responding the endpoint MUST send the INIT ACK back to the same address that the original INIT (sent by this endpoint) was sent to. 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. When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with an INIT ACK the 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. --------- Old text: (Section 5.2.2) --------- Stewart, et al. Expires August 30, 2003 [Page 14] Internet-Draft SCTP Implementer's Guide March 2003 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT Unless otherwise stated, upon reception of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. In the outbound INIT ACK the endpoint MUST copy its current Verification Tag and peer's Verification Tag into a reserved place within the state cookie. We shall refer to these locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag (randomly generated see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g. number of outbound streams) into the INIT ACK and cookie. After sending out the INIT ACK, the endpoint shall take no further actions, i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed. Note: Only when a TCB exists and the association is not in a COOKIE- WAIT state are the Tie-Tags populated. For a normal association INIT (i.e. the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed). The INIT ACK and State Cookie are populated as specified in section 5.2.1. --------- New text: (Section 5.2.2) --------- 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT Unless otherwise stated, upon reception of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. Before responding the endpoint MUST check to see if the unexpected INIT adds new addresses to the association. If new addresses are added to the association, the endpoint MUST respond with an ABORT copying the 'Initiation Tag' of the unexpected INIT into the 'Verification Tag' of the outbound packet carrying the ABORT. In the ABORT response the cause of error SHOULD be set to 'restart of an association with new addresses'. The error SHOULD list the addresses that were added to the restarting association. If no new addresses are added, when responding to the INIT in the outbound INIT ACK the endpoint MUST copy its current Verification Tag and peer's Verification Tag into a reserved place within the state cookie. We shall refer to these locations as the Peer's-Tie-Tag and Stewart, et al. Expires August 30, 2003 [Page 15] Internet-Draft SCTP Implementer's Guide March 2003 the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag (randomly generated see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g. number of outbound streams) into the INIT ACK and cookie. After sending out the INIT ACK or ABORT, the endpoint shall take no further actions, i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed. Note: Only when a TCB exists and the association is not in a COOKIE- WAIT, COOKIE-ECHOED or SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a value other than 0. For a normal association INIT (i.e. the endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed). 2.6.3 Solution description A new error code is being added and specific instructions to send back an ABORT to a new association in a restart case or collision case, where new addresses have been added. The error code can be used by a legitimate restart to inform the endpoint that it has made a software error in adding a new address. The endpoint then can choose to wait until the OOTB ABORT tears down the old association, or restart without the new address. Also the Note at the end of section 5.2.2 explaining the use of the Tie-Tags was modified to properly explain the states in which the Tie-Tags should be set to a value different than 0. 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes 2.7.1 Description of the problem Some implementations were having difficulty growing their cwnd. This was due to an improper enforcement of the congestion control rules. The rules, as written, provided for a slop over of the cwnd value. Without this slop over the sender would appear to NOT be using its full cwnd value and thus never increase it. Stewart, et al. Expires August 30, 2003 [Page 16] Internet-Draft SCTP Implementer's Guide March 2003 2.7.2 Text changes to the document --------- Old text: (Section 6.1) --------- B) At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd or more bytes of data outstanding to that transport address. --------- New text: (Section 6.1) --------- B) At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd or more bytes of data outstanding to that transport address. The sender may exceed cwnd by up to (PMTU-1) bytes on a new transmission if the cwnd is not currently exceeded. 2.7.3 Solution description The text changes make clear the ability to go over the cwnd value by no more than (PMTU-1) bytes. 2.8 Issues with Fast Retransmit 2.8.1 Description of the problem Several problems were found in the current specification of fast retransmit. The current wording did not require GAP ACK blocks to be sent, even though they are essential to the workings of SCTP's congestion control. The specification left unclear how to handle the fast retransmit cycle, having the implementation to wait on the cwnd to retransmit a TSN that was marked for fast retransmit. No limit was placed on how many times a TSN could be fast retransmitted. Fast Recovery was not specified, causing the congestion window to be reduced drastically when there are multiple losses in a single RTT. 2.8.2 Text changes to the document --------- Old text: (Section 6.2) --------- Acknowledgments MUST be sent in SACK chunks unless shutdown was Stewart, et al. Expires August 30, 2003 [Page 17] Internet-Draft SCTP Implementer's Guide March 2003 requested by the ULP in which case an endpoint MAY send an acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field SHOULD also be reported in the Gap Ack Block fields. --------- New text: (Section 6.2) --------- Acknowledgments MUST be sent in SACK chunks unless shutdown was requested by the ULP in which case an endpoint MAY send an acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field are reported in the Gap Ack Block fields. The SCTP endpoint MUST report as many Gap Ack Blocks that can fit in a single SACK chunk limited by the current path MTU. --------- Old text: (Section 7.2.4) --------- Whenever an endpoint receives a SACK that indicates some TSN(s) missing, it SHOULD wait for 3 further miss indications (via subsequent SACK's) on the same TSN(s) before taking action with regard to Fast Retransmit. When the TSN(s) is reported as missing in the fourth consecutive SACK, the data sender shall: 1) Mark the missing DATA chunk(s) for retransmission, 2) Adjust the ssthresh and cwnd of the destination address(es) to which the missing DATA chunks were last sent, according to the formula described in Section 7.2.3. 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the path MTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit those K DATA chunks in a single packet. Stewart, et al. Expires August 30, 2003 [Page 18] Internet-Draft SCTP Implementer's Guide March 2003 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest outstanding TSN number sent to that address, or the endpoint is retransmitting the first outstanding DATA chunk sent to that address. Note: Before the above adjustments, if the received SACK also acknowledges new DATA chunks and advances the Cumulative TSN Ack Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 must be applied first. A straightforward implementation of the above keeps a counter for each TSN hole reported by a SACK. The counter increments for each consecutive SACK reporting the TSN hole. After reaching 4 and starting the fast retransmit procedure, the counter resets to 0. Because cwnd in SCTP indirectly bounds the number of outstanding TSN's, the effect of TCP fast-recovery is achieved automatically with no adjustment to the congestion control window size. --------- New text: (Section 7.2.4) --------- Whenever an endpoint receives a SACK that indicates some TSN(s) missing, it SHOULD wait for 3 further miss indications (via subsequent SACK's) on the same TSN(s) before taking action with regard to Fast Retransmit. Miss indications SHOULD follow the HTNA (Highest TSN Newly Acknowledged) algorithm. For each incoming SACK, miss indications are incremented only for missing TSNs prior to the highest TSN newly acknowledged in the SACK. A newly acknowledged DATA chunk is one not previously acknowledged in a SACK. If an endpoint is in Fast Recovery and a SACK arrives that advances the Cumulative TSN Ack Point, the miss indications are incremented for all TSNs reported missing in the SACK. When the fourth consecutive miss indication is recieved for a TSN(s), the data sender shall: 1) Mark the DATA chunk(s) with four miss indications for retransmission. 2) If not in Fast Recovery, adjust the ssthresh and cwnd of the destination address(es) to which the missing DATA chunks were last sent, according to the formula described in Section 7.2.3. 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the path MTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit Stewart, et al. Expires August 30, 2003 [Page 19] Internet-Draft SCTP Implementer's Guide March 2003 those K DATA chunks in a single packet. When a Fast Retransmit is being performed the sender SHOULD ignore the value of cwnd and SHOULD NOT delay retransmission for this single packet. 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest outstanding TSN number sent to that address, or the endpoint is retransmitting the first outstanding DATA chunk sent to that address. 5) Mark the DATA chunk(s) as being fast retransmitted and thus ineligible for a subsequent fast retransmit. Those TSNs marked for retransmission due to the Fast Retransmit algorithm that did not fit in the sent datagram carrying K other TSNs are also marked as ineligible for a subsequent fast retransmit. However, as they are marked for retransmission they will be retransmitted later on as soon as cwnd allows. 6) If not in Fast Recovery, enter Fast Recovery and mark the highest outstanding TSN as the Fast Recovery exit point. When a SACK acknowledges all TSNs up to and including this exit point, Fast Recovery is exited. While in Fast Recovery, the ssthresh and cwnd SHOULD NOT change for any destinations. Note: Before the above adjustments, if the received SACK also acknowledges new DATA chunks and advances the Cumulative TSN Ack Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 must be applied first. 2.8.3 Solution description The effect of the above wording changes are as follows: o It requires with a MUST the sending of GAP Ack blocks instead of the current RFC2960 [4] SHOULD. o It allows a TSN being Fast Retransmitted (FR) to be sent only once via FR. o It ends the delay in awaiting for the flight size to drop when a TSN is identified ready to FR. o It changes the way chunks are marked during fast retransmit, so that only new reports are counted. o It introduces a Fast Recovery period to avoid multiple congestion window reductions when there are multiple losses in a single RTT Stewart, et al. Expires August 30, 2003 [Page 20] Internet-Draft SCTP Implementer's Guide March 2003 (as shown by Caro et al. [3]). These changes will effectively allow SCTP to follow a similar model as TCP+SACK in the handling of Fast Retransmit. 2.9 Missing statement about partial_bytes_acked update 2.9.1 Description of the problem SCTP uses four control variables to regulate its transmission rate: rwnd, cwnd, ssthresh and partial_bytes_acked. Upon detection of packet losses from SACK or when the T3-rtx timer expires on an address cwnd and ssthresh should be updated as stated in section 7.2.3. However, that section should also clarify that partial_bytes_acked must be updated as well, having to be reset to 0. 2.9.2 Text changes to the document --------- Old text: (Section 7.2.3) --------- 7.2.3 Congestion Control Upon detection of packet losses from SACK (see Section 7.2.4), An endpoint should do the following: ssthresh = max(cwnd/2, 2*MTU) cwnd = ssthresh Basically, a packet loss causes cwnd to be cut in half. When the T3-rtx timer expires on an address, SCTP should perform slow start by: ssthresh = max(cwnd/2, 2*MTU) cwnd = 1*MTU --------- New text: (Section 7.2.3) --------- 7.2.3 Congestion Control Upon detection of packet losses from SACK (see Section 7.2.4), an endpoint should do the following: ssthresh = max(cwnd/2, 2*MTU) Stewart, et al. Expires August 30, 2003 [Page 21] Internet-Draft SCTP Implementer's Guide March 2003 cwnd = ssthresh partial_bytes_acked = 0 Basically, a packet loss causes cwnd to be cut in half. When the T3-rtx timer expires on an address, SCTP should perform slow start by: ssthresh = max(cwnd/2, 2*MTU) cwnd = 1*MTU partial_bytes_acked = 0 2.9.3 Solution description The missing text added solves the doubts about what to do with partial_bytes_acked in the situations stated in section 7.2.3, making clear that along with ssthresh and cwnd, partial_bytes_acked should also be updated, having to be reset to 0. 2.10 Issues with Heartbeating and failure detection 2.10.1 Description of the problem Five basic problems have been discovered with the current heartbeat procedures: o The current specification does not specify that you should count a failed heartbeat as an error against the overall association. o The current specification is un-specific as to when you start sending heartbeats and when you should stop. o The current specification is un-specific as to when you should respond to heartbeats. o When responding to a Heartbeat it is unclear what to do if more than a single TLV is present. o The jitter applied to a heartbeat was meant to be a small variance of the RTO and is currently a wide variance due to the default delay time and incorrect wording within the RFC. 2.10.2 Text changes to the document --------- Old text: (Section 8.1) Stewart, et al. Expires August 30, 2003 [Page 22] Internet-Draft SCTP Implementer's Guide March 2003 --------- 8.1 Endpoint Failure Detection An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (including retransmissions to all the destination transport addresses of the peer if it is multi-homed). If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall consider the peer endpoint unreachable and shall stop transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint shall report the failure to the upper layer, and optionally report back all outstanding user data remaining in its outbound queue. The association is automatically closed when the peer endpoint becomes unreachable. The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK), or a HEARTBEAT-ACK is received from the peer endpoint. --------- New text: (Section 8.1) --------- 8.1 Endpoint Failure Detection An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all the destination transport addresses of the peer if it is multi-homed), including unacknowledged HEARTBEAT Chunks. If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall consider the peer endpoint unreachable and shall stop transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint shall report the failure to the upper layer, and optionally report back all outstanding user data remaining in its outbound queue. The association is automatically closed when the peer endpoint becomes unreachable. The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK), or a HEARTBEAT-ACK is received from the peer endpoint. --------- Old text: (Section 8.3) --------- 8.3 Path Heartbeat Stewart, et al. Expires August 30, 2003 [Page 23] Internet-Draft SCTP Implementer's Guide March 2003 By default, an SCTP endpoint shall monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). --------- New text: (Section 8.3) --------- 8.3 Path Heartbeat By default, an SCTP endpoint shall monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). HEARTBEAT sending MAY begin upon reaching the ESTABLISHED state, and is discontinued after sending either SHUTDOWN or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state (INIT sender) or the ESTABLISHED state (INIT receiver), up until reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-ACK-SENT state (SHUTDOWN receiver). --------- Old text: (Section 8.3) --------- The receiver of the HEARTBEAT should immediately respond with a HEARTBEAT ACK that contains the Heartbeat Information field copied from the received HEARTBEAT chunk. --------- New text: (Section 8.3) --------- The receiver of the HEARTBEAT should immediately respond with a HEARTBEAT ACK that contains the Heartbeat Information TLV, together with any other received TLVs, copied unchanged from the received HEARTBEAT chunk. --------- Old text: (Section 8.3) --------- On an idle destination address that is allowed to heartbeat, a HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that destination address plus the protocol parameter 'HB.interval' , with jittering of +/- 50%, and exponential back-off of the RTO if the Stewart, et al. Expires August 30, 2003 [Page 24] Internet-Draft SCTP Implementer's Guide March 2003 previous HEARTBEAT is unanswered. --------- New text: (Section 8.3) --------- On an idle destination address that is allowed to heartbeat, a HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that destination address plus the protocol parameter 'HB.interval' , with jittering of +/- 50% of the RTO value, and exponential back-off of the RTO if the previous HEARTBEAT is unanswered. 2.10.3 Solution description The above text provides guidance as to how to respond to the five issues mentioned in Section 2.10.1 In particular the wording changes provide guidance as to when to start and stop heartbeating, how to respond to a heartbeat with extra parameters, and clarifies the error counting procedures for the association. 2.11 Security interactions with firewalls 2.11.1 Description of the problem When dealing with firewalls it is advantageous to the firewall to be able to properly determine the initial startup sequence of a reliable transport protocol. With this in mind the following text is to be added to SCTP's security section. 2.11.2 Text changes to the document --------- New text: (no old text, new section added) --------- 11.4 SCTP interactions with firewalls It is helpful for some firewalls if they can inspect just the first fragment of a fragmented SCTP packet and unambiguously determine whether it corresponds to an INIT chunk (for further information please refer to RFC1858). Accordingly, we stress the requirements stated in 3.1 that (1) an INIT chunk MUST NOT be bundled with any other chunk in a packet, and (2) a packet containing an INIT chunk MUST have a zero Verification Tag. Furthermore, we require that the receiver of an INIT chunk MUST enforce these rules by silently discarding an arriving packet with an Stewart, et al. Expires August 30, 2003 [Page 25] Internet-Draft SCTP Implementer's Guide March 2003 INIT chunk that is bundled with other chunks. --------- Old text: (Section 18) --------- 18. Bibliography [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999. [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21. [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, March 1997. [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997. [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999. [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29(5), October 1999. --------- New text: (Section 18) --------- 18. References [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999. [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21. [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Stewart, et al. Expires August 30, 2003 [Page 26] Internet-Draft SCTP Implementer's Guide March 2003 Security", RFC 1750, December 1994. [RFC1858] Ziemba, G., Reed, D. and Traina P., "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995. [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, March 1997. [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997. [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999. [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29(5), October 1999. 2.11.3 Solution description The above text adding a new subsection to the Security Considerations section of RFC2960 [4] makes clear that, to make easier the interaction with firewalls, an INIT chunk must not be bundled in any case with any other chunk, being this rule enforced by the packet receiver, that will silently discard the packets that do not follow this rule. 2.12 Shutdown ambiguity 2.12.1 Description of the problem Currently there is an ambiguity between the statements in section 6.2 and section 9.2. Section 6.2 allows the sending of a SHUTDOWN chunk in place of a SACK when the sender is in the process of shutting down, while section 9.2 requires both a SHUTDOWN chunk and a SACK chunk to be sent. Along with this ambiguity there is a problem where in an errant SHUTDOWN receiver may fail to stop accepting user data. 2.12.2 Text changes to the document Stewart, et al. Expires August 30, 2003 [Page 27] Internet-Draft SCTP Implementer's Guide March 2003 --------- Old text: (Section 9.2) --------- If there are still outstanding DATA chunks left, the SHUTDOWN receiver shall continue to follow normal data transmission procedures defined in Section 6 until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user. While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunk(s) with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If it has no more outstanding DATA chunks, the SHUTDOWN receiver shall send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must re-send the SHUTDOWN ACK. --------- New text: (Section 9.2) --------- If there are still outstanding DATA chunks left, the SHUTDOWN receiver shall continue to follow normal data transmission procedures defined in Section 6 until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user. While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunk(s) with a SHUTDOWN chunk, and restart the T2-shutdown timer. If a SHUTDOWN chunk by itself cannot acknowledge all of the received DATA chunks (i.e. there are TSN's that can be acknowledged that are larger than the cumulative TSN and thus gaps exist in the TSN sequence) or if duplicate TSN's have been recieved then a SACK chunk MUST also be sent. The sender of the SHUTDOWN MAY also start an overall guard timer 'T5-shutdown-guard' to bound the overall time for shutdown sequence. At the expiration of this timer the sender SHOULD abort the association by sending an ABORT chunk. If the 'T5-shutdown-guard' timer is used, it SHOULD be set to the recommended value of 5 times 'RTO.Max'. If the receiver of the SHUTDOWN has no more outstanding DATA chunks, the SHUTDOWN receiver shall send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must re-send the SHUTDOWN ACK. Stewart, et al. Expires August 30, 2003 [Page 28] Internet-Draft SCTP Implementer's Guide March 2003 2.12.3 Solution description The above text clarifies the use of a SACK in conjunction with a SHUTDOWN chunk. It also adds a guard timer to the SCTP shutdown sequence to protect against errant receivers of SHUTDOWN chunks. 2.13 Inconsistency in ABORT processing 2.13.1 Description of the problem It was noted that the wording in section 8.5.1 did not give proper directions in the use of the 'T bit' with the verification tags. 2.13.2 Text changes to the document Stewart, et al. Expires August 30, 2003 [Page 29] Internet-Draft SCTP Implementer's Guide March 2003 --------- Old text: (Section 8.5.1) --------- B) Rules for packet carrying ABORT: - The endpoint shall always fill in the Verification Tag field of the outbound packet with the destination endpoint's tag value if it is known. - If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 8.4. - The receiver MUST accept the packet if the Verification Tag matches either its own tag, OR the tag of its peer. Otherwise, the receiver MUST silently discard the packet and take no further action. --------- New text: (Section 8.5.1) --------- B) Rules for packet carrying ABORT: - The endpoint shall always fill in the Verification Tag field of the outbound packet with the destination endpoint's tag value if it is known. - If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 8.4. - The receiver of a ABORT shall accept the packet if the Verification Tag field of the packet matches its own tag OR it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action. 2.13.3 Solution description The above text change clarifies that the T bit must be set before an implementation looks for the peers tag. 2.14 Cwnd gated by its full use 2.14.1 Description of the problem A problem was found with the current specification of the growth and Stewart, et al. Expires August 30, 2003 [Page 30] Internet-Draft SCTP Implementer's Guide March 2003 decay of cwnd. The cwnd should only be increased if it is being fully utilized, and after periods of under utilization, the cwnd should be decreased. In some sections, the current wording is weak and is not clearly defined. Also, the current specification unnecessarily introduces the need for special case code to ensure cwnd degradation. Plus, the cwnd should not be increased during Fast Recovery since a full cwnd during Fast Recovery does not qualify the cwnd as being fully utilized. Additionally, multiple loss scenarios in a single window may cause the cwnd to grow more rapidly as the number of losses in a window increases [3]. 2.14.2 Text changes to the document --------- Old text: (Section 6.1) --------- D) Then, the sender can send out as many new DATA chunks as Rule A and Rule B above allow. --------- New text: (Section 6.1) --------- D) When the time comes for the sender to transmit new DATA chunks, the protocol parameter Max.Burst MUST first be applied to limit how many new DATA chunks may be sent. The limit is applied by adjusting cwnd as follows: if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + Max.Burst*MTU E) Then, the sender can send out as many new DATA chunks as Rule A and Rule B above allow. --------- Old text: (Section 7.2.1) --------- o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST use the slow start algorithm to increase cwnd (assuming the current congestion window is being fully utilized). If an incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be increased by at most the lesser of 1) the total size of the previously outstanding DATA chunk(s) acknowledged, and 2) the destination's path MTU. This protects against the ACK-Splitting attack outlined in [SAVAGE99]. Stewart, et al. Expires August 30, 2003 [Page 31] Internet-Draft SCTP Implementer's Guide March 2003 --------- New text: (Section 7.2.1) --------- o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST use the slow start algorithm to increase cwnd only if the current congestion window is being fully utilized, an incoming SACK advances the Cumulative TSN Ack Point, and the data sender is not in Fast Recovery. Only when these three conditions are met can the cwnd be increased otherwise the cwnd MUST not be increased. If these conditions are met then cwnd MUST be increased by at most the lesser of 1) the total size of the previously outstanding DATA chunk(s) acknowledged, and 2) the destination's path MTU. This protects against the ACK-Splitting attack outlined in [SAVAGE99]. --------- Old text: (Section 7.2.1) --------- o When the endpoint does not transmit data on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd/2, 2*MTU) per RTO. --------- New text: (Section 7.2.1) --------- o When the association does not transmit data on a given transport address within an RTO, the cwnd of the transport address SHOULD be adjusted to 2*MTU. --------- Old text: (Section 7.2.2) --------- o Same as in the slow start, when the sender does not transmit DATA on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd / 2, 2*MTU) per RTO. --------- New text: (Section 7.2.2) --------- o Same as in the slow start, when the sender does not transmit DATA on a given transport address within an RTO, the cwnd of the transport address should be adjusted to 2*MTU. --------- Stewart, et al. Expires August 30, 2003 [Page 32] Internet-Draft SCTP Implementer's Guide March 2003 Old text: (Section 14) --------- 14. Suggested SCTP Protocol Parameter Values The following protocol parameters are RECOMMENDED: RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.interval - 30 seconds --------- New text: (Section 14) --------- 14. Suggested SCTP Protocol Parameter Values The following protocol parameters are RECOMMENDED: RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds Max.Burst - 4 RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.Interval - 30 seconds 2.14.3 Solution description The above changes strengthens the rules and makes it much more apparent as to the need to block cwnd growth when the full cwnd is not being utilized. The changes also applies cwnd degradation without introducing the need for complex special case code. 2.15 Window probes in SCTP Stewart, et al. Expires August 30, 2003 [Page 33] Internet-Draft SCTP Implementer's Guide March 2003 2.15.1 Description of the problem When a receiver clamps its rwnd to 0 to flow control the peer, the specification implies that one must continue to accept data from the remote peer. This is incorrect and needs clarification. 2.15.2 Text changes to the document --------- Old text: (Section 6.2) --------- The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk. --------- New text: (Section 6.2) --------- The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk when the DATA chunk received is inside its receive window. When the receiver's advertised window is 0, the receiver MUST drop all new incoming DATA chunk and immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk MUST NOT be included in the SACK as they were not accepted. The receiver MUST also have an algorithm for advertising its receive window to avoid receiver silly window syndrome (SWS) as described in RFC 813. The algorithm can be similar to the one described in Section 4.2.3.3 of RFC 1122. Because of receiver SWS avoidance, even when the receiver's internal buffer is not full anymore, as long as the advertised window is still 0, the receiver MUST still drop all new incoming DATA chunk. --------- Old text: (Section 6.1) --------- A) At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicates that the peer has no buffer space (i.e. rwnd is 0, see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK having been lost in transit from the data Stewart, et al. Expires August 30, 2003 [Page 34] Internet-Draft SCTP Implementer's Guide March 2003 receiver to the data sender. --------- New text: (Section 6.1) --------- A) At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicates that the peer has no buffer space (i.e. rwnd is 0, see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK having been lost in transit from the data receiver to the data sender. When the receiver's advertised window is zero, this probe is called a zero window probe. 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. Zero window probing MUST be supported. When a sender is doing zero window probing, it should not time out the association if it continues to receive new packets from the receiver. The reason is that the receiver MAY keep its window closed for an indefinite time. Refer to Section 6.2 on the receiver behavior when it advertises a zero window. The sender SHOULD send the first zero window probe after 1 RTO when it detects that the receiver has closed its window, and SHOULD increase the probe interval exponentially afterwards. Also note that the cwnd SHOULD be adjusted according to Section 7.2.1. Zero window probing does not affect the calculation of cwnd. The sender MUST also have algorithm in sending new DATA chunks to avoid silly window syndrome (SWS) as described in RFC 813. The algorithm can be similar to the one described in Section 4.2.3.4 of RFC 1122. 2.15.3 Solution description The above allows a receiver to drop new data that arrives and yet still requires the receiver to send a SACK showing the conditions unchanged (with the possible exception of a new a_rwnd) and the dropped chunk as missing. This will allow the association to continue until the rwnd condition clears. Stewart, et al. Expires August 30, 2003 [Page 35] Internet-Draft SCTP Implementer's Guide March 2003 2.16 Fragmentation and Path MTU issues 2.16.1 Description of the problem The current wording of the Fragmentation and Reassembly forces an implementation that supports fragmentation to always fragment. This prohibits an implementation from offering its users an option to disable sends that exceed the SCTP fragmentation point. The restriction in RFC2960 [4] section 6.9 was never meant to restrict an implementations API from this behavior. 2.16.2 Text changes to the document --------- Old text: (Section 6.1) --------- 6.9 Fragmentation and Reassembly An endpoint MAY support fragmentation when sending DATA chunks, but MUST support reassembly when receiving DATA chunks. If an endpoint supports fragmentation, it MUST fragment a user message if the size of the user message to be sent causes the outbound SCTP packet size to exceed the current MTU. If an implementation does not support fragmentation of outbound user messages, the endpoint must return an error to its upper layer and not attempt to send the user message. IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer. --------- New text: (Section 6.1) --------- 6.9 Fragmentation and Reassembly An endpoint MAY support fragmentation when sending DATA chunks, but MUST support reassembly when receiving DATA chunks. If an endpoint supports fragmentation, it MUST fragment a user message if the size of the user message to be sent causes the outbound SCTP packet size to exceed the current MTU. If an implementation does not support fragmentation of outbound user messages, the endpoint must return an error to its upper layer and not attempt to send the user message. Note: If an implementation that supports fragmentation makes Stewart, et al. Expires August 30, 2003 [Page 36] Internet-Draft SCTP Implementer's Guide March 2003 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. IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer. 2.16.3 Solution description The above wording will allow an implementation to offer the option of rejecting sends that exceed the P-MTU size even when the implementation supports fragmentation. 2.17 Initial value of the cumulative TSN Ack 2.17.1 Description of the problem The current description of the SACK chunk within the RFC does not clearly state the value that would be put within a SACK when no DATA chunk has been received. 2.17.2 Text changes to the document --------- Old text: (Section 3.3.4) --------- Cumulative TSN Ack: 32 bits (unsigned integer) This parameter contains the TSN of the last DATA chunk received in sequence before a gap. --------- New text: (Section 3.3.4) --------- Cumulative TSN Ack: 32 bits (unsigned integer) This parameter contains the TSN of the last DATA chunk received in sequence before a gap. In the case where no DATA chunk has been received, this value is set to the peers Initial TSN minus one. Stewart, et al. Expires August 30, 2003 [Page 37] Internet-Draft SCTP Implementer's Guide March 2003 2.17.3 Solution description This change clearly states what the initial value will be for a SACK sender. 2.18 Handling of address parameters within the INIT or INIT-ACK 2.18.1 Description of the problem The current description on handling address parameters contained within the INIT and INIT-ACK do not fully describe a requirement for their handling. 2.18.2 Text changes to the document Stewart, et al. Expires August 30, 2003 [Page 38] Internet-Draft SCTP Implementer's Guide March 2003 --------- Old text: (Section 5.1.2) --------- C) If there are only IPv4/IPv6 addresses present in the received INIT or INIT ACK chunk, the receiver shall derive and record all the transport address(es) from the received chunk AND the source IP address that sent the INIT or INIT ACK. The transport address(es) are derived by the combination of SCTP source port (from the common header) and the IP address parameter(s) carried in the INIT or INIT ACK chunk and the source IP address of the IP datagram. The receiver should use only these transport addresses as destination transport addresses when sending subsequent packets to its peer. --------- New text: (Section 5.1.2) --------- C) If there are only IPv4/IPv6 addresses present in the received INIT or INIT ACK chunk, the receiver shall derive and record all the transport address(es) from the received chunk AND the source IP address that sent the INIT or INIT ACK. The transport address(es) are derived by the combination of SCTP source port (from the common header) and the IP address parameter(s) carried in the INIT or INIT ACK chunk and the source IP address of the IP datagram. The receiver should use only these transport addresses as destination transport addresses when sending subsequent packets to its peer. 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. 2.18.3 Solution description This new text clearly specifies to an implementor the need to look within the INIT or INIT-ACK. Any implementation that does not do this, may not be able to establish associations in certain circumstances. 2.19 Handling of stream shortages Stewart, et al. Expires August 30, 2003 [Page 39] Internet-Draft SCTP Implementer's Guide March 2003 2.19.1 Description of the problem The current wording in the RFC places the choice of sending an ABORT upon the SCTP stack when a stream shortage occurs. This decision should really be made by the upper layer not the SCTP stack. 2.19.2 Text changes to the document --------- Old text: --------- 5.1.1 Handle Stream Parameters In the INIT and INIT ACK chunks, the sender of the chunk shall indicate the number of outbound streams (OS) it wishes to have in the association, as well as the maximum inbound streams (MIS) it will accept from the other endpoint. After receiving the stream configuration information from the other side, each endpoint shall perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants to configure, the endpoint MUST either use MIS outbound streams, or abort the association and report to its upper layer the resources shortage at its peer. --------- New text: (Section 5.1.2) --------- 5.1.1 Handle Stream Parameters In the INIT and INIT ACK chunks, the sender of the chunk shall indicate the number of outbound streams (OS) it wishes to have in the association, as well as the maximum inbound streams (MIS) it will accept from the other endpoint. After receiving the stream configuration information from the other side, each endpoint shall perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants to configure, the endpoint MUST use MIS outbound streams and MAY report any shortage to the upper layer. The upper layer can then choose to abort the association if the resource shortage is unacceptable. Stewart, et al. Expires August 30, 2003 [Page 40] Internet-Draft SCTP Implementer's Guide March 2003 2.19.3 Solution description The above changes take the decision to ABORT out of the realm of the SCTP stack and places it into the users hands. 2.20 Indefinite postponement 2.20.1 Description of the problem The current RFC does not provide any guidance on the assignment of TSN sequence numbers to outbound message nor reception of these message. This could lead to a possible indefinite postponement. 2.20.2 Text changes to the document Stewart, et al. Expires August 30, 2003 [Page 41] Internet-Draft SCTP Implementer's Guide March 2003 --------- Old text: (Section 6.1) --------- Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 1 above the beginning TSN of the current send window. 6.2 Acknowledgment on Reception of DATA Chunks --------- New text: (Section 6.1) --------- Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 1 above the beginning TSN of the current send window. The algorithm by which an implementation assigns sequential TSNs to messages on a particular association MUST ensure that no user message that has been accepted by SCTP is indefinitely postponed from being assigned a TSN. Acceptable algorithms for assigning TSNs include (a) assigning TSNs in round-robin order over all streams with pending data (b) preserving the linear order in which the user messages were submitted to the SCTP association. When an upper layer requests to read data on an SCTP association, the SCTP receiver SHOULD choose the message with the lowest TSN from among all deliverable messages. In SCTP implementations that allow a user to request data on a specific stream, this operation SHOULD NOT block if data is not available, since this can lead to a deadlock under certain conditions. 6.2 Acknowledgment on Reception of DATA Chunks 2.20.3 Solution description The above wording clarifies how TSNs SHOULD be assigned by the sender. 2.21 User initiated abort of an association 2.21.1 Description of the problem It is not possible for an upper layer to abort the association and Stewart, et al. Expires August 30, 2003 [Page 42] Internet-Draft SCTP Implementer's Guide March 2003 provide the peer with an indication why the association is aborted. 2.21.2 Text changes to the document Some of the changes given here already include changes suggested in section Section 2.6 of this document. --------- Old text: (Section 3.3.10) --------- Cause Code Value Cause Code --------- ---------------- 1 Invalid Stream Identifier 2 Missing Mandatory Parameter 3 Stale Cookie Error 4 Out of Resource 5 Unresolvable Address 6 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 8 Unrecognized Parameters 9 No User Data 10 Cookie Received While Shutting Down Cause Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields Cause-specific Information: variable length This field carries the details of the error condition. Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3. --------- New text: (Section 3.3.10) --------- Cause Code Value Cause Code --------- ---------------- 1 Invalid Stream Identifier 2 Missing Mandatory Parameter Stewart, et al. Expires August 30, 2003 [Page 43] Internet-Draft SCTP Implementer's Guide March 2003 3 Stale Cookie Error 4 Out of Resource 5 Unresolvable Address 6 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 8 Unrecognized Parameters 9 No User Data 10 Cookie Received While Shutting Down 11 Restart of an association with new addresses 12 User Initiated Abort Cause Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields Cause-specific Information: variable length This field carries the details of the error condition. Sections 3.3.10.1 - 3.3.10.12 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3. --------- New text: (Note no old text, new error added in section 3.3.10) --------- 3.3.10.12 User Initiated Abort (12) Cause of error -------------- This error cause MAY be included in ABORT chunks which are send because of an upper layer request. The upper layer can specify an Upper Layer Abort Reason which is transported by SCTP transparently and MAY be delivered to the upper layer protocol at the peer. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=12 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Upper Layer Abort Reason / \\ \\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------- Old text: (Section 9.1) Stewart, et al. Expires August 30, 2003 [Page 44] Internet-Draft SCTP Implementer's Guide March 2003 --------- 9.1 Abort of an Association When an endpoint decides to abort an existing association, it shall send an ABORT chunk to its peer endpoint. The sender MUST fill in the peer's Verification Tag in the outbound packet and MUST NOT bundle any DATA chunk with the ABORT. An endpoint MUST NOT respond to any received packet that contains an ABORT chunk (also see Section 8.4). An endpoint receiving an ABORT shall apply the special Verification Tag check rules described in Section 8.5.1. After checking the Verification Tag, the receiving endpoint shall remove the association from its record, and shall report the termination to its upper layer. --------- New text: (Section 9.1) --------- 9.1 Abort of an Association When an endpoint decides to abort an existing association, it shall send an ABORT chunk to its peer endpoint. The sender MUST fill in the peer's Verification Tag in the outbound packet and MUST NOT bundle any DATA chunk with the ABORT. If the association is aborted on request of the upper layer an User Initiated Abort error cause (see 3.3.10.12) SHOULD be present in the ABORT chunk. An endpoint MUST NOT respond to any received packet that contains an ABORT chunk (also see Section 8.4). An endpoint receiving an ABORT shall apply the special Verification Tag check rules described in Section 8.5.1. After checking the Verification Tag, the receiving endpoint shall remove the association from its record, and shall report the termination to its upper layer. If an User Initiated Abort error cause is present in the ABORT chunk the Upper Layer Abort Reason shall be made available to the upper layer. --------- Old text: (Section 10.1) --------- Stewart, et al. Expires August 30, 2003 [Page 45] Internet-Draft SCTP Implementer's Guide March 2003 D) Abort Format: ABORT(association id [, cause code]) -> result Ungracefully closes an association. Any locally queued user data will be discarded and an ABORT chunk is sent to the peer. A success code will be returned on successful abortion of the association. If attempting to abort the association results in a failure, an error code shall be returned. Mandatory attributes: o association id - local handle to the SCTP association Optional attributes: o cause code - reason of the abort to be passed to the peer. --------- New text: (Section 10.1) --------- D) Abort Format: ABORT(association id [, Upper Layer Abort Reason]) -> result Ungracefully closes an association. Any locally queued user data will be discarded and an ABORT chunk is sent to the peer. A success code will be returned on successful abortion of the association. If attempting to abort the association results in a failure, an error code shall be returned. Mandatory attributes: o association id - local handle to the SCTP association Optional attributes: o Upper Layer Abort Reason - reason of the abort to be passed to the peer. None. --------- Old text: (Section 10.2) --------- Stewart, et al. Expires August 30, 2003 [Page 46] Internet-Draft SCTP Implementer's Guide March 2003 E) COMMUNICATION LOST notification When SCTP loses communication to an endpoint completely (e.g., via Heartbeats) or detects that the endpoint has performed an abort operation, it shall invoke this notification on the ULP. The following shall be passed with the notification: o association id - local handle to the SCTP association o status - This indicates what type of event has occurred; The status may indicate a failure OR a normal termination event occurred in response to a shutdown or abort request. The following may be passed with the notification: o data retrieval id - an identification used to retrieve unsent and unacknowledged data. o last-acked - the TSN last acked by that peer endpoint; o last-sent - the TSN last sent to that peer endpoint; --------- New text: (Section 10.2) --------- E) COMMUNICATION LOST notification When SCTP loses communication to an endpoint completely (e.g., via Heartbeats) or detects that the endpoint has performed an abort operation, it shall invoke this notification on the ULP. The following shall be passed with the notification: o association id - local handle to the SCTP association o status - This indicates what type of event has occurred; The status may indicate a failure OR a normal termination event occurred in response to a shutdown or abort request. The following may be passed with the notification: o data retrieval id - an identification used to retrieve unsent and unacknowledged data. o last-acked - the TSN last acked by that peer endpoint; Stewart, et al. Expires August 30, 2003 [Page 47] Internet-Draft SCTP Implementer's Guide March 2003 o last-sent - the TSN last sent to that peer endpoint; o Upper Layer Abort Reason - the abort reason specified if case of an user initiated abort. 2.21.3 Solution description The above allows an upper layer to provide its peer with an indication why the association was aborted. Therefore an addition error cause was introduced. 2.22 Handling of invalid Initiate Tag of INIT-ACK 2.22.1 Description of the problem RFC 2960 requires that the receiver of an INIT-ACK with the Initiate Tag set to zero handles this as an error and sends back an ABORT. But the sender of the INIT-ACK normally has no TCB and so the ABORT is useless. 2.22.2 Text changes to the document Stewart, et al. Expires August 30, 2003 [Page 48] Internet-Draft SCTP Implementer's Guide March 2003 --------- Old text: (Section 3.3.3) --------- Initiate Tag: 32 bits (unsigned integer) The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the INIT ACK receiver transmits within this association. The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value. If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0, the receiver MUST treat it as an error and close the association by transmitting an ABORT. --------- New text: (Section 3.3.3) --------- Initiate Tag: 32 bits (unsigned integer) The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the INIT ACK receiver transmits within this association. The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value. If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0, the receiver MUST destroy the association discarding its TCB. The receiver MAY send an ABORT for debugging purpose. 2.22.3 Solution description The new text does not require the receiver of the invalid INIT-ACK to send the ABORT. This behavior is in tune with the error case of invalid stream numbers in the INIT-ACK. However it is allowed to send an ABORT for debugging purposes. 2.23 ABORT sending in response to an INIT Stewart, et al. Expires August 30, 2003 [Page 49] Internet-Draft SCTP Implementer's Guide March 2003 2.23.1 Description of the problem Whenever the receiver of an INIT chunk has to send an ABORT chunk in response for whatever reason it is not stated clearly which Verification Tag and value of the T-bit should be used. 2.23.2 Text changes to the document --------- Old text: (Section 8.4) --------- 3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. Otherwise, --------- New text: (Section 8.4) --------- 3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. If, for whatever reason, the INIT can not be processed normally and an ABORT has to be sent in response, the Verification Tag of the packet containing the ABORT chunk MUST be the Initiate tag of the received INIT chunk and the T-Bit of the ABORT chunk has to be set to 1 indicating that a TCB was destroyed. Otherwise, 2.23.3 Solution description The new text stated clearly which value of the Verification Tag and T-bit have to be used. 2.24 Stream Sequence Number (SSN) Initialization 2.24.1 Description of the problem RFC 2960 does not describe the fact that the SSN have to initialized to 0 in he way it is required by RFC2119. Stewart, et al. Expires August 30, 2003 [Page 50] Internet-Draft SCTP Implementer's Guide March 2003 2.24.2 Text changes to the document --------- Old text: (Section 6.5) --------- The stream sequence number in all the streams shall start from 0 when the association is established. Also, when the stream sequence number reaches the value 65535 the next stream sequence number shall be set to 0. --------- New text: (Section 6.5) --------- The stream sequence number in all the streams MUST start from 0 when the association is established. Also, when the stream sequence number reaches the value 65535 the next stream sequence number MUST be set to 0. 2.24.3 Solution description The 'shall' in the text is replaced by a 'MUST' to clearly state the required behavior. 2.25 SACK packet format 2.25.1 Description of the problem It is not clear in RFC 2960 whether a SACK must contain the fields Number of Gap Ack Blocks and Number of Duplicate TSNs or not. Stewart, et al. Expires August 30, 2003 [Page 51] Internet-Draft SCTP Implementer's Guide March 2003 2.25.2 Text changes to the document --------- Old text: (Section 3.3.4) --------- The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver Window Credit (a_rwnd) parameters. --------- New text: (Section 3.3.4) --------- The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver Window Credit (a_rwnd), Number of Gap Ack Blocks, and Number of Duplicate TSNs fields. 2.25.3 Solution description The text has been modified. It is now clear that a SACK always contains the fields Number of Gap Ack Blocks and Number of Duplicate TSNs. 2.26 Protocol Violation Error Cause 2.26.1 Description of the problem There are many situations a SCTP endpoints detects that the peer violates the protocol. Therefore the association has to be aborted. Currently there are only some error causes which could be used to indicate the reason of the abort but these do not cover all cases. 2.26.2 Text changes to the document Some of the changes given here already include changes suggested in section Section 2.6 and Section 2.21 of this document. --------- Old text: (Section 3.3.10) --------- Cause Code Value Cause Code --------- ---------------- 1 Invalid Stream Identifier Stewart, et al. Expires August 30, 2003 [Page 52] Internet-Draft SCTP Implementer's Guide March 2003 2 Missing Mandatory Parameter 3 Stale Cookie Error 4 Out of Resource 5 Unresolvable Address 6 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 8 Unrecognized Parameters 9 No User Data 10 Cookie Received While Shutting Down Cause Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields Cause-specific Information: variable length This field carries the details of the error condition. Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3. --------- New text: (Section 3.2.10) --------- Cause Code Value Cause Code --------- ---------------- 1 Invalid Stream Identifier 2 Missing Mandatory Parameter 3 Stale Cookie Error 4 Out of Resource 5 Unresolvable Address 6 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 8 Unrecognized Parameters 9 No User Data 10 Cookie Received While Shutting Down 11 Restart of an association with new addresses 12 User Initiated Abort 13 Protocol Violation Cause Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Cause Stewart, et al. Expires August 30, 2003 [Page 53] Internet-Draft SCTP Implementer's Guide March 2003 Code, Cause Length, and Cause-Specific Information fields Cause-specific Information: variable length This field carries the details of the error condition. Sections 3.3.10.1 - 3.3.10.13 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3. --------- New text: (Note no old text, new error added in section 3.3.10) --------- 3.3.10.13 Protocol Violation (13) Cause of error -------------- This error cause MAY be included in ABORT chunks which are send because a SCTP endpoint detects a protocol violation of the peer which is not covered by the error causes described in 3.3.10.1 to 3.3.10.12. An implementation MAY provide Additional Information specifying what kind of protocol violation has been detected. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=13 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Additional Information / \\ \\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.26.3 Solution description An additional error cause which can be used by an endpoint to indicate a protocol violation of the peer has been defined. 2.27 Reporting of Unrecognized Parameters 2.27.1 Description of the problem It is not stated clearly in RFC2960 [4] how unrecognized parameters should be reported. Unrecognized parameters in an INIT chunk could be reported in the INIT-ACK chunk or in a separate ERROR chunk which can get lost. Unrecognized parameters in an INIT-ACK chunk have to Stewart, et al. Expires August 30, 2003 [Page 54] Internet-Draft SCTP Implementer's Guide March 2003 be reported in an ERROR-chunk. This can be bundled with the COOKIE-ERROR chunk or sent separately. If it is sent separately and received before the COOKIE-ECHO it will be handled as an OOTB packet resulting in sending out an ABORT chunk. Therefore the association would not be established. 2.27.2 Text changes to the document Some of the changes given here already include changes suggested in section Section 2.2 of this document. --------- Old text: (Section 3.2.1) --------- 00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it. 01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK). 10 - Skip this parameter and continue processing. 11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK). --------- New text: (Section 3.2.1) --------- 00 - Stop processing this SCTP chunk and discard it, do not process any further parameters within this chunk. 01 - Stop processing this SCTP chunk and discard it, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter Type' as described in 3.2.2. 10 - Skip this parameter and continue processing. 11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type' as described in 3.2.2. Stewart, et al. Expires August 30, 2003 [Page 55] Internet-Draft SCTP Implementer's Guide March 2003 --------- New text: (Note no old text, clarification added in section 3.2) --------- 3.2.2 Reporting of Unrecognized Parameters If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to section 3.2.1 it MUST put the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in response to the INIT-chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g. due to lack of resources) then no report would be sent back. If the receiver of an INIT-ACK chunk detects unrecognized parameters and has to report them according to section 3.2.1 it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameters' error cause with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. If the receiver of the INIT-ACK can not bundle the COOKIE-ECHO chunk with the ERROR chunk the ERROR chunk MAY be sent separately but not before the COOKIE-ACK has been received. Note: Any time a COOKIE-ECHO is sent in a packet it MUST be the first chunk. 2.27.3 Solution description The procedure of reporting unrecognized parameters has been described clearly. 2.28 Handling of IP Address Parameters 2.28.1 Description of the problem It is not stated clearly in RFC2960 [4] how a SCTP endpoint which supports either IPv4 addresses or IPv6 addresses should respond if IPv4 and IPv6 addresses are presented by the peer in the INIT or INIT-ACK chunk. Stewart, et al. Expires August 30, 2003 [Page 56] Internet-Draft SCTP Implementer's Guide March 2003 2.28.2 Text changes to the document --------- Old text: (Section 5.1.2) --------- IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers. --------- New text: (Section 5.1.2) --------- IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers. IMPLEMENTATION NOTE: If a SCTP endpoint only supporting either IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-ACK chunk from its peer it MUST use all of the addresses belonging to the supported address family. The other addresses MAY be ignored. The endpoint SHOULD NOT respond with any kind of error indication. 2.28.3 Solution description The procedure of handling IP address parameters has been described clearly. 2.29 Handling of COOKIE ECHO chunks when a TCB exists 2.29.1 Description of the problem The description of be behavior in RFC2960 [4] when a COOKIE ECHO chunk and a TCB exists could be misunderstood. When a COOKIE ECHO is received, a TCB exist and the local and peer's tag match it is stated that the endpoint should enter the ESTABLISHED state if it has not already done so and send a COOKIE ACK. It was not clear that in case the endpoint has already left again the ESTABLISHED state then it should not go back to established. In case D the endpoint can only enter state ESTABLISHED from COOKIE-ECHOED because in state CLOSED it Stewart, et al. Expires August 30, 2003 [Page 57] Internet-Draft SCTP Implementer's Guide March 2003 has no TCB and in state COOKIE-WAIT it has a TCB but knows nothing about the peer's tag which is requested to match in this case. 2.29.2 Text changes to the document --------- Old text: (Section 5.2.4) --------- D) When both local and remote tags match the endpoint should always enter the ESTABLISHED state, if it has not already done so. It should stop any init or cookie timers that may be running and send a COOKIE ACK. --------- New text: (Section 5.2.4) --------- D) When both local and remote tags match the endpoint should enter the ESTABLISHED state, if it is in the COOKIE-ECHOED state. It should stop any cookie timer that may be running and send a COOKIE ACK. 2.29.3 Solution description The procedure of handling of COOKIE-ECHO chunks when a TCB exists has been described clearly. Stewart, et al. Expires August 30, 2003 [Page 58] Internet-Draft SCTP Implementer's Guide March 2003 3. Acknowledgments The authors would like to thank the following people that have provided comments and input for this document: Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, Manoj Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Glaude, Jon Berger, Jon Grim, Dan Harrison, Sabina Torrente, Tomas Orti Martin, Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben Robinson, David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, Melissa Campbell, Sujith Radhakrishnan, Andreas Jungmaier, Mitch Miers, Fred Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Kacheong Poon, Sverre Slotte, Wang Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep Mahajan, RCMonee, Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep Balani, Biren Patel, Qiaobing Xie, Karl Knutson, La Monte Yarroll, Gareth Keily, Ian Periam, Nathalie Mouellic, Atsushi Fukumoto, David Lehmann, Rob Brennan, Thomas Curran, Stan McClellan, Keyur Shah, and Janardhan Iyengar. A special thanks to Mark Allman, who should actually be a co-author for his work on the max-burst, but managed to wiggle out due to a technicality. Stewart, et al. Expires August 30, 2003 [Page 59] Internet-Draft SCTP Implementer's Guide March 2003 References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Caro, A., Shah, K., Iyengar, J., Amer, P. and R. Stewart, "SCTP and TCP Variants: Congestion Control Under Multiple Losses", Technical Report TR2003-04, Computer and Information Sciences Department, University of Delaware, February 2003, . [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. Authors' Addresses Randall R. Stewart Cisco Systems, Inc. 8725 West Higgins Road Suite 300 Chicago, IL 60631 USA Phone: EMail: rrs@cisco.com Lyndon Ong Ciena Systems 10480 Ridgeview Ct Cupertino, CA 95014 USA Phone: EMail: lyong@ciena.com Stewart, et al. Expires August 30, 2003 [Page 60] Internet-Draft SCTP Implementer's Guide March 2003 Ivan Arias-Rodriguez Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland Phone: EMail: ivan.arias-rodriguez@nokia.com Kacheong Poon CA Phone: EMail: kcpoon@yahoo.com Phillip T. Conrad Temple University CIS Department Room 303, Computer Building (038-24) 1805 N. Broad St. Philadelphia, PA 19122 US Phone: +1 215 204 7910 EMail: conrad@acm.org URI: http://www.cis.temple.edu/~conrad Armando L. Caro Jr. University of Delaware Department of Computer & Information Sciences 103 Smith Hall Newark, DE 19716 USA Phone: EMail: acaro@cis.udel.edu URI: http://www.cis.udel.edu/~acaro Stewart, et al. Expires August 30, 2003 [Page 61] Internet-Draft SCTP Implementer's Guide March 2003 Michael Tuexen Siemens AG ICN WN CC SE 7 D-81359 Munich Germany Phone: EMail: Michael.Tuexen@siemens.com Stewart, et al. Expires August 30, 2003 [Page 62] Internet-Draft SCTP Implementer's Guide March 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Stewart, et al. Expires August 30, 2003 [Page 63] Internet-Draft SCTP Implementer's Guide March 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stewart, et al. Expires August 30, 2003 [Page 64] --------------030607060300010001060302-- From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Feb 24 10:28:05 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 KAA16675 for ; Mon, 24 Feb 2003 10:28: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-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1OFJHB6019702 for ; Mon, 24 Feb 2003 07:19:17 -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 h1OFIwTS021070 for ; Mon, 24 Feb 2003 07:18:58 -0800 (PST) Received: from stewart.chicago.il.us ([67.38.193.238]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1OFHiT6022817 for ; Mon, 24 Feb 2003 07:17:45 -0800 (PST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1OFE7DY007734 for ; Mon, 24 Feb 2003 09:14:07 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E5A36BE.8090603@stewart.chicago.il.us> Date: Mon, 24 Feb 2003 09:14:06 -0600 From: Randall Stewart 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 Implementors Subject: apologies Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all: I must apologize for sending the pre-next implementors guide to the lsit.. I see in my address book I have two names that are to close to each other sctp-implementors-guide co-authors and sctp-implementors You all are welcome to comment on the document... you sorta got a "pre-look" :> R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Feb 24 19:41:58 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 TAA01604 for ; Mon, 24 Feb 2003 19:41:54 -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 h1P0ZnHK027334 for ; Mon, 24 Feb 2003 16:35:49 -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 h1P0a5SQ012115 for ; Mon, 24 Feb 2003 16:36:05 -0800 (PST) Received: from mail.nrd.jp (iplab08.nara.wide.ad.jp [203.178.142.17]) by proxy3.cisco.com (8.12.2/8.11.2) with SMTP id h1P0aACc025856 for ; Mon, 24 Feb 2003 16:36:12 -0800 (PST) Received: (qmail 37445 invoked from network); 25 Feb 2003 09:31:57 +0900 Received: from unknown (HELO ?127.0.0.1?) (203.178.142.17) by iplab08.nara.wide.ad.jp with SMTP; 25 Feb 2003 09:31:57 +0900 Date: Tue, 25 Feb 2003 09:31:30 +0900 From: Katsuyoshi IIDA To: sctp-impl@external.cisco.com Subject: new internet-draft has been submitted Cc: Randall Stewart , lode.coene@siemens.atea.be, Peter , toshi-ku@is.aist-nara.ac.jp Message-Id: <20030225084653.B4CC.KATSU@is.aist-nara.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Content-Transfer-Encoding: 7bit Hi SCTP professionals, My name is Katsuyoshi Iida, Nara Institute of Science and Technology, Japan. Our research group are now extensively working on researches in the SCTP area. One of our members, Toshiyuki Kubo, and I have just submitted an internet draft, which deals with "single point of failure" problem in SCTP. (Currently, its file name is not assigned by the IETF secretariat.) I would like to kindly ask you to read our document, which is attached in this email. Any feedbacks are welcome. Sincerely yours, -- Graduate School of Information Science Nara Institute of Science and Technology, Japan. Assistant Professor Katsuyoshi Iida, Ph.D Email: Phone: +81-743-72-5213 Fax: +81-743-72-5219 ---- cut here ---- Network Working Group Toshiyuki Kubo Internet Draft Katsuyoshi Iida Expiration Date: August 2003 Nara Institute of Science and Technology February 2003 Path based route identification in SCTP Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Although SCTP provides multihoming function, a single point of failure may occur due to its lack of source address selection. RFC2960 describes that "a host should pick the most divergent source- destination pair." But, it also describes that selecting source address is implementation matter. In RFC3257, Coene et al. have claimed that a host must take careful in selectiong its source address. In this document, we propose a way of outgoing interface selection and its corresponding source address selection in SCTP. Toshiyuki, et al. [Page 1] Internet Draft February 2003 Table of Contents Section 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2 Section 2. Single point of failure in SCTP . . . . . . . . . . . . . 5 Section 3. Path based route identification . . . . . . . . . . . . 7 Section 3.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . 7 Section 3.2 Path parameters notification . . . . . . . . . . . . . . 8 Section 3.3 Path choosing algorithm . . . . . . . . . . . . . . . . 10 Section 4. Security Considerations . . . . . . . . . . . . . . . . . 12 Section 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 12 Section 6. References . . . . . . . . . . . . . . . . . . . . . . . 12 Section 7. Authors Information . . . . . . . . . . . . . . . . . . . 13 1. Introduction Although SCTP [RFC2960] provides multihoming function, a single point of failure may occur due to its lack of source address selection. RFC2960 describes that "a host should pick the most divergent source- destination pair." But, it also describes that selecting source address is implementation matter. In [RFC3257], Coene et al. have claimed that a host must take careful in selectiong its source address. To avoid this problem, Coene et al. have shown an example of routing table setting [SCTP-MULTIHOME], as a solution of "single point of failure". We explain this using Fig. 1.1. In the figure, there are two endpoints: Endpoints A and Endpoints B. Both of endpoints have two interfaces and hence two addresses. The routing table to avoid single point of failure is described in Tab. 1.1. Both routing table contain all address of their corresponding endpoint and vice versa. +------------+ *~~~~~~~~~* +------------+ | Endpoint A | * Cloud * | Endpoint B | | 1.2 +---------+ 1.1 3.1 +----------+ 3.2 | | | | | | | | 2.2 +---------+ 2.1 4.1 +----------+ 4.2 | | | * * | | +------------+ *~~~~~~~~~* +------------+ Figure 1.1: Two hosts with redundant networks. Toshiyuki, et al. [Page 2] Internet Draft February 2003 Table 1.1: Routing tables in two hosts to avoid single point of failure Endpoint A Endpoint B Destination Gateway Destination Gateway ------------------------ ------------------------ 3.0 1.1 1.0 3.1 4.0 2.1 2.0 4.1 There are two drawbacks for this solution. First, these routing table setting depends on each SCTP association. This means we need to have different routing settings for different SCTP association. Figure 1.2 and Tab. 1.2 illustrate this difficulty. There are two associations: Endpoint A <-> Endpoint B and Endpoint A <-> Endpoint C. Here, End- point A is required to have different entries for each peer of end- points. In this way, this method is not practical because routing ta- ble setup is needed before each association establishment. +------------+ *~~~~~~~~~* +------------+ | Endpoint A | * Cloud * | Endpoint B | | 1.2 +---------+ 1.1 3.1 +----------+ 3.2 | | | | | | | | 2.2 +---------+ 2.1 4.1 +----------+ 4.2 | | | * 5.1 6.1 * | | +------------+ *~~~+~~+~~* +------------+ | | | | +----+--+----+ | 5.2 6.2 | | | | | | Endpoint C | | | +------------+ Figure 1.2: Three hosts with redundant networks. Toshiyuki, et al. [Page 3] Internet Draft February 2003 Table 1.2: Routing tables in three hosts to avoid single point of failure. Endpoint A Endpoint B Destination Gateway Destination Gateway ------------------------ ------------------------ 3.0 1.1 1.0 3.1 4.0 2.1 2.0 4.1 5.0 1.1 6.0 2.1 Endpoint C Destination Gateway ------------------------ 1.0 5.1 2.0 6.1 Second, when the number of interfaces of an endpoint is different from that of its corresponding endpoint for an association, the num- ber or routes to be used becomes the smaller number of interfaces. Therefore, we cannot take the advantage of redundancy of the endpoint with the larger number of interfaces. In this document, we propose a way of outgoing interface selection and its corresponding source address selection in SCTP. The main fea- ture of our proposal is the simultaneous address switching, i.e., when an endpoint switches its destination address, then it also changes its source address simultaneously. We call a combination of source address and destination address "path". In order to implement the path based route identification, we need to modify both IP routing and route identification mechanisms in SCTP. However, the required modification of IP routing is very simple: End- point must have multiple default routes, each of which corresponds to each outgoing interface. This avoids the impracticality mentioned before. Meanwhile, the current SCTP endpoint identifies "a destination address" as a route. Instead, in our proposal, an endpoint identifies "a path", that represents a route to be used in failover. This enables us the correct data paths without complicated routing setup. Moreover, each endpoint maintains a set of parameters that represents route characteristics for each path. The parameters includes error counter, cwnd, and RTO. The advantages of our scheme are the followings. o It can avoid the "single point of failure". Toshiyuki, et al. [Page 4] Internet Draft February 2003 o Routing setup for each association establishment is not needed because of multiple default routes. o Since we choose the number of paths as the larger number of interfaces, we can take full advantage of redundancy of two endpoints. This is particularly useful for the two-to-one association, that consists of an endpoint with two interfaces and that with one. With the original SCTP, the association has no redundancy. o Since we do not establish the full-mesh paths, the amount of state increases becomes negligible. There are some scenarios that our proposal is useful. o VPN. VPN needs to have long term association setup. For exam- ple, endpoint A subscribes ISP X (with address x.a) and ISP Y (with y.a), and endpoint B also subscribes ISP X (with x.b) and ISP Y (with y.b). In this scenario, Only two paths are enough, say, (x.a <-> x.b) and (y.a <-> y.b). In this way, it can avoid to use meaningless routes including (x.a <-> y.b) and (x.b <-> y.a). o Mobile scenario. Suppose the two-to-one topology, and the end- point with two interfaces is mobile station. In this example, two different error counters are needed on the mobile station because it has two different wireless interfaces. Our solution provides different error counters for each outgoing inter- faces, although this cannot be provided by the original SCTP. 2. Single point of failure in SCTP One of the reasons behind the SCTP standardization is to increase the redundancy of a level of the transport protocol. However, there are many situations that cannot be solved by the current SCTP. In this section, we explain what are situations and/or what kind of "single point of failure" we are focusing on. Toshiyuki, et al. [Page 5] Internet Draft February 2003 +------------+ *~~~~~~~~~* +------------+ | Endpoint A | * Cloud * | Endpoint B | | 1.2 +---------+ 1.1<--+ | | | | | | |->3.1|----------+ 3.2 | | 2.2 +---------+ 2.1<--+ | | | | | * * | | +------------+ *~~~~~~~~~* +------------+ Figure 2.1: Two-to-one topology. Table 2.1: Typical routing tables in two-to-one topology. Endpoint A Endpoint B Destination Gateway Destination Gateway ------------------------ ------------------------ default 1.1 default 3.1 1.0 direct 3.0 direct 2.0 direct In Fig. 2.1, we illustrate an association between Endpoint A and End- point B, where Endpoint A has two interfaces with addresses 1.2 and 2.2, and Endpoint B has one interface with address 3.2. In other words, Endpoint A is multihomed, but Endpoint B is not. We call this configuration "two-to-one topology". Here, the link between 3.1 and 3.2 becomes a single point of failure, but this single point of fail- ure is natural and unavoidable. Therefore, we do not care about this in the remaining of this document. We then explain what kind of "single point of failure" we are focus- ing on using an example of the two-to-one topology. In this example, our target "single point of failure" is the link between 1.1 and 1.2. To explain this we first describe typical routing tables of both end- points in Tab. 2.1, since single point of failure we focus is strongly related to the IP routing. According to Endpoint A's routing table, packets from Endpoint A are going out at 1.2, although Endpoint A may receive packets at 1.2 and 2.2. Thus, there is only one route actually used in the direction from Endpoint A to Endpoint B, while there is an alternate route in the same direction. In this way, the link between 1.1 and 1.2 becomes "single point of failure", although it is avoidable. Therefore, when the link becomes down, all the packets going through from Endpoint A to Endpoint B will be lost in a consequence of the association fail- ure. Note that a character of "single point of failure" we focus on is that a HEARTBEAT and its HEARTBEAT-ACK form a triangle: 3.2 -> 2.2 -> Toshiyuki, et al. [Page 6] Internet Draft February 2003 1.2 -> 3.2. This happens when Endpoint B choose 2.2 as destination of a HEARTBEAT. Moreover, "single point of failure" we focus on also occurs in cases with many other topological configurations e.g. the two-to-two topol- ogy. Among them, the two-to-one topology is the simplest configura- tion. 3. Path based route identification 3.1 Basics We then propose a path based route identification in SCTP to avoid "single point of failure" without a routing table setup for each association. The proposal consists of both IP layer's and SCTP layer's modifications. Meanwhile, there is no solid definition of terminology of "path" in the current literature of SCTP, although the term appears in many documents. Therefore, we would like to define "path" first. Our def- inition of "path" is a combination of a source address and a destina- tion address. This enables us to differentiate two different source addresses even with the same destination address. For example, in Fig. 2.1, there exits two paths (1.2 - 3.2) and (2.2 - 3.2). As a consequence, Endpoint A with path based route identifi- cation will continue successful packet deliveries even when the link between 1.1 and 1.2 fails. To implement the path based route identification in SCTP, modifica- tions of the IP routing are required because the traditional IP rout- ing cannot differentiate two source addresses with the same destina- tion address. This can be achieved by source address attaching enhancement of routing table, that is illustrated in Tab 3.1 as an example of the two-to-one topology in Fig. 2.1. Toshiyuki, et al. [Page 7] Internet Draft February 2003 Endpoint A Source Destination Gateway ---------------------------------------- 1.2 default 1.1 2.2 default 2.1 1.2 1.0 direct 2.2 2.0 direct Endpoint B Source Destination Gateway ---------------------------------------- 3.2 default 3.1 3.2 3.0 direct Table 3.1. Source address attached routing tables in two-to-one topology. When Endpoint A's SCTP stack selects the path (1.2 -> 3.2), it employs the entry of the first line. Otherwise, it chooses the entry of the second line. We note that "path" can be bidirectional, i.e., associations maintain each direction of path. Thus, the numbers of routes for both direc- tions completely agree. Finally, for information those of who would like to implement this, there are some implementations of source address attaching enhance- ment of IP routing [STAR]. Also see our paper that deals with the implementation [PATH-MANAGEMENT]. In summary of this section, we have described IP layer's modifica- tion, which is required to avoid "single point of failure". We then explain SCTP layer's modification in the rest of this sections. 3.2 Path parameters notification Next, we propose a minor modification of the INIT-ACK phase to real- ize the path based route identification in SCTP. To ensure consis- tency of path parameters in both endpoints, the endpoint that receives the INIT chunk first creates some paths as combinations of one of own addresses and one of address contained by INIT chunk. Then it compiles the path parameters into the INIT-ACK chunk. More details about path creation are described in Section 3.3. Figure 3.1 illustrates proposed path parameters that are attached with the INIT-ACK chunk. There are two kinds of path parameters for IPv4 and for IPv6. Here we define an "initiator" endpoint as the Toshiyuki, et al. [Page 8] Internet Draft February 2003 endpoint that sent the INIT chunk, a "responder" endpoint as the end- point that receives the INIT chunk. As we already described in the previous section, a path is a combination of a source address and a destination address, i.e., a combination of one of initiator addresses and one of responder addresses. (a) IPv4 Path Parameter (0xb000) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xb000 | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Responder Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Initiator Address: 32 bits (unsigned integer) IPv4 Responder Address: 32 bits (unsigned integer) (b) IPv6 Path Parameter (0xb001) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xb001 | Length = 36 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Initiator Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Responder Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Initiator Address: 128 bits (unsigned integer) IPv6 Responder Address: 128 bits (unsigned integer) Figure 3.1. Proposed path parameters for IPv4 and IPv6. To deliver path information from the responder to the initiator, we introduce a new parameter, called path parameter that includes a pair of initiator address and responder address. If the responder creates four paths, then four path parameters will be included in total. Toshiyuki, et al. [Page 9] Internet Draft February 2003 When the responder endpoint sends out the INIT-ACK chunk, it does not store any path related information in its memory, to protect DoS packets as same as the original SCTP. Therefore, the initiator end- point saves this information into a cookie data. More precise descriptions about our modifications are shown in Fig. 3.2 as a form of BNF notations. ::= | ::= | | | ::= ::= ::= ::= ::= | | ::= | ::= Figure 3.2. BNF notations of proposed INIT-ACK chunk Note that the initiator endpoint can piggy-back user data into the COOKIE-ECHO chunk, also as same as the original SCTP. This is the reason why we decide the responder creates the path parameters when it receives the INIT chunk. 3.3 Path choosing algorithm Theoretically, in case with the full-mesh paths, the maximum number of paths is equal to n * m, where n is the number of interfaces of the initiator, and m is that of the responder. Therefore, the amount of memory required to maintain paths may be exhausted if we choose the full-mesh paths with large n and/or large m. Moreover, it gives us excessive redundancy. For example, in case with the two-to-two topology, the number of paths becomes four. Since at least one alter- native path is enough for redundancy, the full-mesh path seems to be excessive. Here, we propose a path choosing algorithm, which chooses a sub set of paths from the full-mesh paths. Our algorithm is very simple but effective to increase the network redundancy with less memory con- sumption. We note that reason why we call "path choosing algorithm" is that the full-mesh paths are defined naturally, and our doing is just choosing some parts of the full-mesh paths. Toshiyuki, et al. [Page 10] Internet Draft February 2003 We first define some symbols. Let a_1, a_2, ..., a_n be the initiator addresses in the order written in the INIT chunk. We denote b_1, b_2, ..., b_m are the responder addresses in the order written in the path parameters explained in Section 3.2. Then, we describe our algorithm in the followings. 1) Choose paths (a_1, b_1), (a_2, b_2), ... (a_l, b_l), where l = n if (n < m), l = m if (m > n), otherwise l = m = n. 2) if (n < m), choose paths (a_n, b_(n+1)), (a_n, b_(n+2)), ..., (a_n, b_m). 3) if (m < n), choose paths (a_(m+1), b_m), (a_(m+2), b_m), ..., (a_n, b_m). In our algorithm, the number of chosen paths is equal to larger value of n or m. This is different from the original SCTP. In the original SCTP, the number of unidirectional routes from the initiator to the responder may be different from that in the reverse direction. Therefore, the num- ber of bidirectional routes is equal to smaller value of n or m. This is another representation that indicates our proposal gives better redundancy than the original SCTP. For example, in the two-to-one topol- ogy, we have no redundancy on the original SCTP. However, our proposal establishes two bidirectional routes. In summary, comparisons in terms of the number of bidirectional routes among some algorithms are shown by (original SCTP) < (our proposal) < (full-mesh path). This means the full-mesh path gives us the maximum redundancy but costly. On the other hand, our algorithm pays small amount of cost to attain an appropriate level of redundancy. One drawback of our algorithm is that it is difficult to avoid undesir- able combination of initiator address and responder address. Consider the two-to-two topology (Fig. 1), and suppose the following situations. 1.2 and 4.2 are belonging to the same ISP X, or 2.2 and 3.2 are belong- ing to the same ISP Y. Since we fix which path should be chosen, we can- not avoid a path establishment between an address with ISP X and that with ISP Y. This is not desirable. Therefore, more sophisticated path choosing algorithm is needed to meet this requirement. Toshiyuki, et al. [Page 11] Internet Draft February 2003 4. Security Considerations There is no security consideration. 5. Acknowledgments We would like to express our gratitude to Mr. Randall Stewart of Cisco Systems for his valuable comments on source address selection. We also thank to Associate Professor Youki Kadobayashi of NAIST for his comments on the path choosing algorithm and for his tremendous encouragements. We are deeply indebted to Professor Suguru Yamaguchi of NAIST for his untiring supports of this project. Great thanks go to our project members: Mr. Shigeru Kashihara, Mr. Takashi Nishiyama and Mr. Kosuke Hata of NAIST for their assistance of our development and for their stimulating discussions. 6. References [RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, "Stream Control Transmission Protocol.", RFC 2960, October 2000. [RFC3257] L. Coene, "SCTP Applicability Statement.", RFC 3257, April 2002. [SCTP-MULTIHOME] Coene, et al, "Multihoming issues in the Stream Control Trans- mission Protocol.", , February 2002. [STAR] T. Kaji, "Development and Implementation of routing strategy switching mechanism for regional IX."(in japanese), Master's thesis, Nara Institute of Science and Technology, March 1998. [PATH-MANAGEMENT] T. Kubo, S. Kashihara, K. Iida, Y. Kadobayashi, S. Yamaguchi, "Path Management of SCTP to Eliminate Single Point of Failure in Multihoming.", In Proc. IEEE 5th International Conference on Advanced Communication Technology(ICACT2003), Phoenix Park, Korea, January 2003. http://sctp.aist-nara.ac.jp/icact2003.pdf Toshiyuki, et al. [Page 12] Internet Draft February 2003 7. Authors Information Toshiyuki Kubo Graduate School of Information Science, Nara Institute of Science and Technology (NAIST) 8916-5 Takayama, Ikoma 630-0192, Japan. Tel: +81-743-72-5216, Fax: +81-743-72-5219 E-mail: toshi-ku@is.aist-nara.ac.jp Katsuyoshi Iida Graduate School of Information Science, Nara Institute of Science and Technology (NAIST) 8916-5 Takayama, Ikoma 630-0192, Japan. Tel: +81-743-72-5213, Fax: +81-743-72-5219 E-mail: katsu@is.aist-nara.ac.jp Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this doc- ument itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Toshiyuki, et al. [Page 13] From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Feb 24 20:22:49 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 UAA02362 for ; Mon, 24 Feb 2003 20:22: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-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1P1HbHK023546 for ; Mon, 24 Feb 2003 17:17:37 -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 h1P1Hrdu007568 for ; Mon, 24 Feb 2003 17:17:53 -0800 (PST) Received: from gw.openss7.com (IDENT:lkTjp2Nrvoy5jKUcNSt2eFOimuJ3R/Rs@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1P1GCT6023489 for ; Mon, 24 Feb 2003 17:16:13 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:P6EvXhWmGPm0nLsae+y13Y8wcACglqdW@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1P1CVD10220; Mon, 24 Feb 2003 18:12:31 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1P1CVc04753; Mon, 24 Feb 2003 18:12:31 -0700 Date: Mon, 24 Feb 2003 18:12:31 -0700 From: "Brian F. G. Bidulock" To: Katsuyoshi IIDA Cc: sctp-impl@external.cisco.com, Randall Stewart , lode.coene@siemens.atea.be, Peter , toshi-ku@is.aist-nara.ac.jp Subject: Re: new internet-draft has been submitted Message-ID: <20030224181231.A4465@openss7.org> Reply-To: bidulock@openss7.org References: <20030225084653.B4CC.KATSU@is.aist-nara.ac.jp> 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: <20030225084653.B4CC.KATSU@is.aist-nara.ac.jp>; from katsu@is.aist-nara.ac.jp on Tue, Feb 25, 2003 at 09:31:30AM +0900 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Katsuyoshi, In general the OpenSS7 implementation does not care how you set up your IP routing tables. If SCTP can find a route to the destination it will use it. If it cannot it cannot. If the packet is a reply to a control chunk (other than SACK), it will attempt to use the source address in the packet to which it is responding. If it cannot reach that source address or the path to that source address is suspect (has been receiving duplicates on SACKs or has excessive retransmissions) it will use the best peer address available. In general, no multihomed configuration need have a network single point of failure. You should investigate some of the available implementations and see how they deal with this situation. I assure you that it is not a problem. If youa are looking for something to research, there are some one-way data flow difficulties with multihoming that might interest you. --brian On Tue, 25 Feb 2003, Katsuyoshi IIDA wrote: > Hi SCTP professionals, > > My name is Katsuyoshi Iida, Nara Institute of Science and Technology, > Japan. Our research group are now extensively working on researches in > the SCTP area. One of our members, Toshiyuki Kubo, and I have just > submitted an internet draft, which deals with "single point of > failure" problem in SCTP. (Currently, its file name is not assigned by > the IETF secretariat.) > > I would like to kindly ask you to read our document, which is attached > in this email. Any feedbacks are welcome. > > Sincerely yours, > -- > Graduate School of Information Science > Nara Institute of Science and Technology, Japan. > Assistant Professor > Katsuyoshi Iida, Ph.D > Email: > Phone: +81-743-72-5213 > Fax: +81-743-72-5219 > [snip] -- 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 Feb 24 21:51:35 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 VAA04242 for ; Mon, 24 Feb 2003 21:51:34 -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 h1P2jdP7024508 for ; Mon, 24 Feb 2003 18:45:39 -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 h1P2jpvO024827 for ; Mon, 24 Feb 2003 18:45:51 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1P2iAT6014818 for ; Mon, 24 Feb 2003 18:44:11 -0800 (PST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h1P2QBcK025427 for ; Mon, 24 Feb 2003 19:26:11 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id TAA18747 for ; Mon, 24 Feb 2003 19:24:32 -0700 (MST)] Received: from Motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id WD6NN8GS; Mon, 24 Feb 2003 20:26:10 -0600 Message-ID: <3E5AD183.F250D818@Motorola.com> Date: Mon, 24 Feb 2003 20:14:27 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kacheong Poon CC: cait@asomi.com, tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <200302170927.DAA13013@parmesan.cs.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I fully agree with Kacheong's assessment that adding the 2nd sequence number to SCTP would constitute a *protocol* change. It would basically alter the semantics of an existing SCTP parameter. If we do that, I don't think anyone knows for sure which existing implementations would be broken and which wouldn't. It would also create a dangerous precedence; if we alter the protocol for the sake of this ULP, there might be many more down the road with a similar "minor" request to change SCTP. Moreover, from a coder's viewpoint, the change may be very easy to make (a couple of lines), but to some one who has already had the old implementation widely deployed (or worse, embedded in some widely sold applications), the cost of upgrading/replacing the stack could be huge. We want to people to think SCTP is stable. Changes of this nature, if easily allowed, would shake people's believe that SCTP is stable and make them wonder if their investment in implementing and deploying SCTP is going to be wasted. Let the ULP have the 2nd sequence number is a better idea, IMO. -Qiaobing Kacheong Poon wrote: > > Included message from Caitlin Bestler : > > >---- > >So, trying to work with SCTP on SCTP's terms, you have three > >possible strategies: > > > >-- Include a SSN-equivalent in the Data Chunk. > > > >-- Allow out-of-order placement of ordered Data chunks. > > > >-- Make SCTP's SSN meaningful for unordered delivery. > > > >The pure ULP solution obviously has the least impact on > >the SCTP layer. But it smacks of having the ULP duplicate > >functionality that rightfully belongs at the transport > >layer. I believe the quick consenseus is that sequenced > >unordered delivery is a natural concept that has value > >beyond any single ULP. > > I don't think that the above functionality "rightfully > belongs to the transport layer (SCTP in this case)." To > me, the unordered delivery mechanism as specified in RFC > 2960 simply means that such data chunks can be delivered > in whatever order the receiver wants. This also > automatically means that the sender can send such chunks > in whatever order it wants if it deems necessary. For > example, an implementation can choose to place a smaller > unordered data chunk ahead in the send queue before a bigger > unordered data chunk. Assuming that the SSN is assigned > when data chunk is sent, to make the suggested change > to RFC 2960 to an implementation may mean more than what > has been discussed. And it is really a protocol change, > not just implementation's choice of how to generate > "arbitrary numbers" to be put in the SSN field of unordered > chunk as it actually places extra restrictions on how an > implementation handled such chunks as described above. > > The SSN in SCTP is designed to be used for order of > delivery by SCTP, that's why it is ignored for unordered > delivery. If an ULP wants to have ordered delivery, don't use > this feature of SCTP. If an ULP wants unordered delivery, but > it still wants to know the sender's sending order, just place > its own sequence number. Overloading the SSN in SCTP, even > if it is assigned by SCTP, not by ULP, is really a bad design > choice. > > Anyway, just my $0.02. BTW, I also cc the SCTP > implementors' list. I believe people there should > be aware of such things. I don't know why that list > was removed from the cc list... > > >---- > > K. Poon. From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Tue Feb 25 02:31:08 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 CAA19259 for ; Tue, 25 Feb 2003 02:31:07 -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 h1P7LXHK017538 for ; Mon, 24 Feb 2003 23:21:33 -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 h1P7LIv7025607 for ; Mon, 24 Feb 2003 23:21:18 -0800 (PST) Received: from zwallet1025.com (66-178-47-93.reverse.newskies.net [66.178.47.93]) by proxy1.cisco.com (8.12.2/8.11.2) with SMTP id h1P7LHVD022295 for ; Mon, 24 Feb 2003 23:21:29 -0800 (PST) Message-Id: <200302250721.h1P7LHVD022295@proxy1.cisco.com> From: Dr Mrs Louise Estrada To: sctp-impl@external.cisco.com Reply-To: drestrada@mail.com Subject: Please Assist Date: Tue, 25 Feb 2003 08:20:29 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="f1ec2460-4899-11d7-b449-525405c4f99e" This is a multi-part message in MIME format --f1ec2460-4899-11d7-b449-525405c4f99e Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dearest, Listen and read carefully, i have found seriousness inyou and that is why i = have decided to involve you in this transaction o.k , i am a woman of = substance andof great importance to my nation and the society ingeneral. i = will not entertain any act of uns eriousnessfrom you in this transaction o.kyou must take instructions from me = at all time and for security reasons you will only communicate me only by my = email for now o.k. I am Dr. Mrs LOUISA EJERCITOR ESTRADA , the wife of Mr Joseph Estrada the = former President of Philippine located in the south east Asia. My husband was = presently impeached from office by a backed uprising of mass demonstrators = and the senate. During my husband's regime as president of Philippine, I realised US$68.5 millions of = dollars from various contract projects I executed successfully. I had planed = to invest this money in Real Estate and Industral Production. Now i have used an NGO to move the money to a bank outside Philippine = awaiting transfer, i want you to assist me transfer the money to your bank = account as the Beneficiary/my Proxy because i do not want the Philippine = Government to trace and confiscate t his one. they have confiscated all our asset. This is the only money left for = me and my family o.k. Now if you agree, i will offer you 40% of the total fund, and you must keep = it very secret and confidential o.k. There is no risk involved, all i want = from you is your corporation so that we can have a sucessful transaction as = all modalities has been put in place i look forward to having a good relationship with you o.k Regards, Dr Mrs Louise Estrade, Wife to former philippine president. --f1ec2460-4899-11d7-b449-525405c4f99e-- From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Tue Feb 25 03:22:38 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 DAA20081 for ; Tue, 25 Feb 2003 03:22: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-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1P8DeHK009821 for ; Tue, 25 Feb 2003 00:13:40 -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 h1P8Dm5m013225 for ; Tue, 25 Feb 2003 00:13:52 -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.2/8.11.2) with ESMTP id h1P8C2T6008356 for ; Tue, 25 Feb 2003 00:12:04 -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 h1PDFHp06145 for ; Tue, 25 Feb 2003 18:45:18 +0530 MIME-Version: 1.0 Message-Id: <3E5B23B8.000003.84637@vijay.india.mercurykr.com> Date: Tue, 25 Feb 2003 13:35:12 +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: Addr in INIT or INIT ACK Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA20081 Hi All, In the sctp-imp-guide version 7, the following paragraph is there .. 2.18.3 Solution description This new text clearly specifies to an implementor the need to look within the INIT or INIT-ACK. Any implementation that does not do this, may not be able to establish associations in certain circumstances. I want to know the circumstances in the which the association will not be established. Regards, Vijay From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Feb 25 04:53:20 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 EAA21939 for ; Tue, 25 Feb 2003 04:53:19 -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 h1P9kU56005707 for ; Tue, 25 Feb 2003 01:46: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 h1P9kU11000952 for ; Tue, 25 Feb 2003 01:46:30 -0800 (PST) Received: from gw.openss7.com (IDENT:eYykukZ7rTOAjSpQfHaKaPg4AMpGm1Tm@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1P9kHVD018808 for ; Tue, 25 Feb 2003 01:46:19 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:SExMu6b7TMUi8UczGw694i0Ky80Mf3Rp@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1P9evD17118; Tue, 25 Feb 2003 02:40:57 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1P9evA12638; Tue, 25 Feb 2003 02:40:57 -0700 Date: Tue, 25 Feb 2003 02:40:57 -0700 From: "Brian F. G. Bidulock" To: Vijay Kumar Choudhary Cc: sctp-impl@external.cisco.com Subject: Re: Addr in INIT or INIT ACK Message-ID: <20030225024057.A12442@openss7.org> Reply-To: bidulock@openss7.org References: <3E5B23B8.000003.84637@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: <3E5B23B8.000003.84637@vijay.india.mercurykr.com>; from vijay@india.mercurykr.com on Tue, Feb 25, 2003 at 01:35:12PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Vijay, The section doesn't really way what problem it is trying to solve, does it? --brian On Tue, 25 Feb 2003, Vijay Kumar Choudhary wrote: > Hi All, > In the sctp-imp-guide version 7, the following paragraph is there .. > > 2.18.3 Solution description > This new text clearly specifies to an implementor the need to look > within the INIT or INIT-ACK. Any implementation that does not do > this, may not be able to establish associations in certain > circumstances. > > I want to know the circumstances in the which the association will not be > established. > > Regards, > Vijay -- 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 Feb 25 05:41:57 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 FAA22850 for ; Tue, 25 Feb 2003 05:41:57 -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 h1PAVY56026768 for ; Tue, 25 Feb 2003 02:31: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 h1PAVYIo026387 for ; Tue, 25 Feb 2003 02:31:34 -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 h1PAVIVD006059 for ; Tue, 25 Feb 2003 02:31:21 -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 h1PFWVp07795 for ; Tue, 25 Feb 2003 21:02:32 +0530 MIME-Version: 1.0 Message-Id: <3E5B43DE.00000B.84637@vijay.india.mercurykr.com> Date: Tue, 25 Feb 2003 15:52:22 +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: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA22850 Hi All, In the sctp imp guide, a new point is added New text: Section 5.1.2 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 want to ask, is it wrong to match only the address received in IP header ? What will happen if i will not match the addresses, which are contained in the INIT or INIT ACK ? Regards, Vijay From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Tue Feb 25 06:44:47 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 GAA24584 for ; Tue, 25 Feb 2003 06:44:45 -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 h1PBciHK011327 for ; Tue, 25 Feb 2003 03:38:44 -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 h1PBd0fl004492 for ; Tue, 25 Feb 2003 03:39:00 -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.2/8.11.2) with ESMTP id h1PBbHT6023439 for ; Tue, 25 Feb 2003 03:37:19 -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 h1PGdBp08700 for ; Tue, 25 Feb 2003 22:09:11 +0530 MIME-Version: 1.0 Message-Id: <3E5B537C.00000D.84637@vijay.india.mercurykr.com> Date: Tue, 25 Feb 2003 16:59:00 +0530 (India Standard Time) Content-Type: Text/Plain X-Mailer: IncrediMail 2001 (1500245) From: "Vijay Kumar Choudhary" References: X-Priority: 3 X-FID: FLAVOR00-NONE-0000-0000-000000000000 To: Subject: RE: Matching addresses in INIT and INIT ACK Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA24584 Hi Ivan, Thanx for ur reply !!!! Now i got it. Regards, Vijay -------Original Message------- From: Ivan.Arias-Rodriguez@nokia.com Date: Tuesday, February 25, 2003 10:00:39 PM To: vijay@india.mercurykr.com; sctp-impl@external.cisco.com Subject: RE: Matching addresses in INIT and INIT ACK Hi Vijay! See my comment below... > Hi All, > In the sctp imp guide, a new point is added > > New text: Section 5.1.2 > > 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 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... > What will happen if i will not match the addresses, which are > contained in > the INIT or INIT ACK ? See above. BR Iván Arias Rodríguez > Regards, > Vijay > From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Feb 25 06:53:22 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 GAA25437 for ; Tue, 25 Feb 2003 06:53:21 -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 h1PBhj6N027245 for ; Tue, 25 Feb 2003 03:43:45 -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 h1PBhD61018134 for ; Tue, 25 Feb 2003 03:43:13 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id h1PBhrCc006343 for ; Tue, 25 Feb 2003 03:43:56 -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 h1PBRqm28682 for ; Tue, 25 Feb 2003 13:27:52 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Feb 2003 13:24:45 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 13:24:44 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 13:24: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: Tue, 25 Feb 2003 13:24:43 +0200 Message-ID: Thread-Index: AcLcu08iNsxcjMe4TYS/T9ctfXJtwgABBbRA From: To: , X-OriginalArrivalTime: 25 Feb 2003 11:24:44.0148 (UTC) FILETIME=[7EF2FB40:01C2DCC0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA25437 Hi Vijay! See my comment below... > Hi All, > In the sctp imp guide, a new point is added > > New text: Section 5.1.2 > > 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 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... > What will happen if i will not match the addresses, which are > contained in > the INIT or INIT ACK ? See above. BR Iván Arias Rodríguez > Regards, > Vijay > From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Feb 25 07:02:19 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 HAA26069 for ; Tue, 25 Feb 2003 07:02:17 -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 h1PBvo56010442 for ; Tue, 25 Feb 2003 03:57:50 -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 h1PBvjLI015941 for ; Tue, 25 Feb 2003 03:57:46 -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 h1PBvaVD008945 for ; Tue, 25 Feb 2003 03:57:37 -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 h1PC0im28473 for ; Tue, 25 Feb 2003 14:00:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Feb 2003 13:57:36 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 13:57:36 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 13:57:36 +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: Addr in INIT or INIT ACK Date: Tue, 25 Feb 2003 13:57:35 +0200 Message-ID: Thread-Topic: Addr in INIT or INIT ACK Thread-Index: AcLctIw/akbFbkGWRTinLDMi508Z3AADUYKQ From: To: , , Cc: , , , , , X-OriginalArrivalTime: 25 Feb 2003 11:57:36.0542 (UTC) FILETIME=[16966BE0:01C2DCC5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA26069 Hi Vijay and Brian! Well, actually, the section doesn't specify exactly what's trying to solve... if you aren't aware in advance about what it is trying to fix, it is difficult to understand why one should do that... But the answer is very easy. The point is that the INIT ACK must be sent to the source address from which the INIT chunk came. However, it can be sent from any of the available source addresses at the INIT ACK sender. Thus, if the INIT ACK receiver doesn't recognize the source address doesn't take a look inside, it can wrongly discard the chunk, not establishing the association... :-( About the INIT... It is a little bit trickier, but there are also some special cases... Imagine the peer restarts and sends you an INIT, including (some of) the previous address as parameters, but using a new address as the source address (or instead of this, you simply have an attacker sending you such an INIT chunk). In this case you should in fact send back and ABORT with the 'Restart of an association with new addresses' cause error. You won't be able to recognize this situation if you don't go through the addresses inside... :-/ I think that we could modify a little section 2.18.3. Currently it says: 2.18.3 Solution description This new text clearly specifies to an implementor the need to look within the INIT or INIT-ACK. Any implementation that does not do this, may not be able to establish associations in certain circumstances. Could it be better something like...?: This new text clearly specifies to an implementor the need to look within the INIT or INIT ACK. Any implementation that does not do this, may for example not be able to recognize an INIT chunk coming from an already established association that adds new addresses (see section 2.6), or an incoming INIT ACK chunk sent from a source address different to the destination address used to send the INIT chunk. How does it sound? BR Iván Arias Rodríguez > -----Original Message----- > From: ext Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Tuesday, 25 February, 2003 11:41 > To: Vijay Kumar Choudhary > Cc: sctp-impl@external.cisco.com > Subject: Re: Addr in INIT or INIT ACK > > > Vijay, > > The section doesn't really way what problem > it is trying to solve, does it? > > --brian > > On Tue, 25 Feb 2003, Vijay Kumar Choudhary wrote: > > > Hi All, > > In the sctp-imp-guide version 7, the following paragraph > is there .. > > > > 2.18.3 Solution description > > This new text clearly specifies to an implementor the > need to look > > within the INIT or INIT-ACK. Any implementation that does not do > > this, may not be able to establish associations in certain > > circumstances. > > > > I want to know the circumstances in the which the > association will not be > > established. > > > > Regards, > > Vijay > > -- > 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 Feb 25 08:36:21 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 IAA00767 for ; Tue, 25 Feb 2003 08:36:16 -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 h1PDQgP7011817 for ; Tue, 25 Feb 2003 05:26:42 -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 h1PDQsl5002449 for ; Tue, 25 Feb 2003 05:26:54 -0800 (PST) Received: from gw.openss7.com (IDENT:7PpMjtoNGgGVJmMRor3FDTZPK3SrSbX2@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1PDODT6001323 for ; Tue, 25 Feb 2003 05:24:14 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:bZjVwZSc2/Z/sqhGNAs6DG8FumK5u3Ly@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1PDKSD21464; Tue, 25 Feb 2003 06:20:28 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1PDKSA15995; Tue, 25 Feb 2003 06:20:28 -0700 Date: Tue, 25 Feb 2003 06:20:27 -0700 From: "Brian F. G. Bidulock" To: Vijay Kumar Choudhary Cc: sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030225062027.A15879@openss7.org> Reply-To: bidulock@openss7.org References: <3E5B537C.00000D.84637@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: <3E5B537C.00000D.84637@vijay.india.mercurykr.com>; from vijay@india.mercurykr.com on Tue, Feb 25, 2003 at 04:59:00PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Iván, But I don't have to look in either the INIT or INIT-ACK to determine this. All I have to do is look in the cookie of the COOKIE-ECHO. (For the second INIT ACK below, the verification tag gives away the establishing association and a second COOKIE-ECHO can be avoided without looking at the address list.) So that doesn't really explain the section to me... Also the section in the IG implies that associations will fail to be formed that would otherwise be formed (not that multiple associations will be attempted to be formed and could fail in one way instead of another). --brian On Tue, 25 Feb 2003, Vijay Kumar Choudhary wrote: > Hi Ivan, > Thanx for ur reply !!!! Now i got it. > > Regards, > Vijay > > > -------Original Message------- > From: Ivan.Arias-Rodriguez@nokia.com > Date: Tuesday, February 25, 2003 10:00:39 PM > To: vijay@india.mercurykr.com; sctp-impl@external.cisco.com > Subject: RE: Matching addresses in INIT and INIT ACK > Hi Vijay! > See my comment below... > > Hi All, > > In the sctp imp guide, a new point is added > > > > New text: Section 5.1.2 > > > > 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 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... > > What will happen if i will not match the addresses, which are > > contained in > > the INIT or INIT ACK ? > See above. > BR Iván Arias Rodríguez > > Regards, > > Vijay > > -- 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 Feb 25 08:51:12 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 IAA01096 for ; Tue, 25 Feb 2003 08:51:11 -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 h1PDh8HK008717 for ; Tue, 25 Feb 2003 05:43:08 -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 h1PDhOKA014580 for ; Tue, 25 Feb 2003 05:43:24 -0800 (PST) Received: from gw.openss7.com (IDENT:wwTHwIOCJqN8fev/brfQuF7XkS9WKYYh@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1PDh0AV020726 for ; Tue, 25 Feb 2003 05:43:10 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:RCHia2+oXtKXfIcBaG95CgkLbWA5REu9@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1PDc5D21874; Tue, 25 Feb 2003 06:38:05 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1PDc4q16206; Tue, 25 Feb 2003 06:38:04 -0700 Date: Tue, 25 Feb 2003 06:38:04 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: sctp-impl@external.cisco.com, vijay@india.mercurykr.com, randall@stewart.chicago.il.us, acaro@acm.org, kcpoon@yahoo.com, lyong@ciena.com, michael.tuexen@icn.siemens.de, conrad@acm.org Subject: Re: Addr in INIT or INIT ACK Message-ID: <20030225063804.B15879@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, Feb 25, 2003 at 01:57:35PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Tue, 25 Feb 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Hi Vijay and Brian! > > Well, actually, the section doesn't specify exactly what's trying to > solve... if you aren't aware in advance about what it is trying to > fix, it is difficult to understand why one should do that... > > But the answer is very easy. The point is that the INIT ACK must be > sent to the source address from which the INIT chunk came. However, it > can be sent from any of the available source addresses at the INIT ACK > sender. Thus, if the INIT ACK receiver doesn't recognize the source > address doesn't take a look inside, it can wrongly discard the chunk, > not establishing the association... :-( One can use the verification tag and destination address of the INIT ACK and need not examine the source address or source address list. > > About the INIT... It is a little bit trickier, but there are also some > special cases... Imagine the peer restarts and sends you an INIT, > including (some of) the previous address as parameters, but using a > new address as the source address (or instead of this, you simply have > an attacker sending you such an INIT chunk). In this case you should > in fact send back and ABORT with the 'Restart of an association with > new addresses' cause error. You won't be able to recognize this > situation if you don't go through the addresses inside... :-/ Restart of an assoc... is only sent when addresses are added, not when the INIT is sent to a different address already belonging to the existing association. Also, IG section 2.6 is quite clear the the INIT addresses need to be examined for new addresses. There seems little reason to vaguely repeat this in 2.18. --brian > > I think that we could modify a little section 2.18.3. Currently it says: > > 2.18.3 Solution description > > This new text clearly specifies to an implementor the need to look > within the INIT or INIT-ACK. Any implementation that does not do > this, may not be able to establish associations in certain > circumstances. > > > Could it be better something like...?: > > This new text clearly specifies to an implementor the need to look > within the INIT or INIT ACK. Any implementation that does not do > this, may for example not be able to recognize an INIT chunk coming > from an already established association that adds new addresses > (see section 2.6), or an incoming INIT ACK chunk sent from a source > address different to the destination address used to send the INIT > chunk. > > > How does it sound? > > BR Iván Arias Rodríguez > > > -----Original Message----- > > From: ext Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Tuesday, 25 February, 2003 11:41 > > To: Vijay Kumar Choudhary > > Cc: sctp-impl@external.cisco.com > > Subject: Re: Addr in INIT or INIT ACK > > > > > > Vijay, > > > > The section doesn't really way what problem > > it is trying to solve, does it? > > > > --brian > > > > On Tue, 25 Feb 2003, Vijay Kumar Choudhary wrote: > > > > > Hi All, > > > In the sctp-imp-guide version 7, the following paragraph > > is there .. > > > > > > 2.18.3 Solution description > > > This new text clearly specifies to an implementor the > > need to look > > > within the INIT or INIT-ACK. Any implementation that does not do > > > this, may not be able to establish associations in certain > > > circumstances. > > > > > > I want to know the circumstances in the which the > > association will not be > > > established. > > > > > > Regards, > > > Vijay > > > > -- > > 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-2.cisco.com Tue Feb 25 09:03:20 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 JAA01430 for ; Tue, 25 Feb 2003 09:03: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 h1PDoDHK012464; Tue, 25 Feb 2003 05:50: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 ADT63419; Tue, 25 Feb 2003 05:50:29 -0800 (PST) Message-ID: <3E5B74A4.5060300@cisco.com> Date: Tue, 25 Feb 2003 07:50: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: Ivan.Arias-Rodriguez@nokia.com CC: sctp-impl@external.cisco.com, vijay@india.mercurykr.com, randall@stewart.chicago.il.us, acaro@acm.org, kcpoon@yahoo.com, lyong@ciena.com, michael.tuexen@icn.siemens.de, conrad@acm.org Subject: Re: Addr in INIT or 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: > Hi Vijay and Brian! > > Well, actually, the section doesn't specify exactly what's trying to solve... if you aren't aware in advance about what it is trying to fix, it is difficult to understand why one should do that... > > But the answer is very easy. The point is that the INIT ACK must be sent to the source address from which the INIT chunk came. However, it can be sent from any of the available source addresses at the INIT ACK sender. Thus, if the INIT ACK receiver doesn't recognize the source address doesn't take a look inside, it can wrongly discard the chunk, not establishing the association... :-( > > About the INIT... It is a little bit trickier, but there are also some special cases... Imagine the peer restarts and sends you an INIT, including (some of) the previous address as parameters, but using a new address as the source address (or instead of this, you simply have an attacker sending you such an INIT chunk). In this case you should in fact send back and ABORT with the 'Restart of an association with new addresses' cause error. You won't be able to recognize this situation if you don't go through the addresses inside... :-/ > > I think that we could modify a little section 2.18.3. Currently it says: > >2.18.3 Solution description > > This new text clearly specifies to an implementor the need to look > within the INIT or INIT-ACK. Any implementation that does not do > this, may not be able to establish associations in certain > circumstances. > > > Could it be better something like...?: > > This new text clearly specifies to an implementor the need to look > within the INIT or INIT ACK. Any implementation that does not do > this, may for example not be able to recognize an INIT chunk coming > from an already established association that adds new addresses > (see section 2.6), or an incoming INIT ACK chunk sent from a source > address different to the destination address used to send the INIT > chunk. > > Sounds good to me Ivan.. I will edit in for the next version we are about to send out :> R > > How does it sound? > > BR Iván Arias Rodríguez > > > >>-----Original Message----- >>From: ext Brian F. G. Bidulock [mailto:bidulock@openss7.org] >>Sent: Tuesday, 25 February, 2003 11:41 >>To: Vijay Kumar Choudhary >>Cc: sctp-impl@external.cisco.com >>Subject: Re: Addr in INIT or INIT ACK >> >> >>Vijay, >> >>The section doesn't really way what problem >>it is trying to solve, does it? >> >>--brian >> >>On Tue, 25 Feb 2003, Vijay Kumar Choudhary wrote: >> >> >> >>>Hi All, >>> In the sctp-imp-guide version 7, the following paragraph >>> >>> >>is there .. >> >> >>>2.18.3 Solution description >>> This new text clearly specifies to an implementor the >>> >>> >>need to look >> >> >>> within the INIT or INIT-ACK. Any implementation that does not do >>> this, may not be able to establish associations in certain >>> circumstances. >>> >>>I want to know the circumstances in the which the >>> >>> >>association will not be >> >> >>>established. >>> >>>Regards, >>>Vijay >>> >>> >>-- >>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 ¦ >> >> > > > > -- 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 Feb 25 09:12:21 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 JAA01574 for ; Tue, 25 Feb 2003 09:12:19 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1PE8hP7016056 for ; Tue, 25 Feb 2003 06:08:43 -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 h1PE8MCQ009069 for ; Tue, 25 Feb 2003 06:08:22 -0800 (PST) Received: from gw.openss7.com (IDENT:CyeZVz2ms5Jk6vpeiITseUJw7GZInAls@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1PE8eAV001582 for ; Tue, 25 Feb 2003 06:08:42 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:8NCUQGEx3Hj6/piohDH0AnwAX2QGbpK7@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1PE5JD22292; Tue, 25 Feb 2003 07:05:19 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1PE5It16566; Tue, 25 Feb 2003 07:05:18 -0700 Date: Tue, 25 Feb 2003 07:05:18 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: sctp-impl@external.cisco.com, vijay@india.mercurykr.com Subject: Re: Addr in INIT or INIT ACK Message-ID: <20030225070518.E15879@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, Feb 25, 2003 at 03:53:48PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Tue, 25 Feb 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > Hi Vijay and Brian! > > > > > > Well, actually, the section doesn't specify exactly what's trying to > > > solve... if you aren't aware in advance about what it is trying to > > > fix, it is difficult to understand why one should do that... > > > > > > But the answer is very easy. The point is that the INIT ACK must be > > > sent to the source address from which the INIT chunk came. However, it > > > can be sent from any of the available source addresses at the INIT ACK > > > sender. Thus, if the INIT ACK receiver doesn't recognize the source > > > address doesn't take a look inside, it can wrongly discard the chunk, > > > not establishing the association... :-( > > > > One can use the verification tag and destination address of the INIT ACK > > and need not examine the source address or source address list. > > I think this has been discussed many times... You are not supposed to > use the VT to identify associations... This is not how the protocol > works... Where is it written that "You are not supposed to use the VT to identify associations..." ??? As it is neither forbidden nor counter-recommended in the RFC it is permitted. And in situations like this it is particularly efficient. --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 Tue Feb 25 09:20:53 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 JAA01757 for ; Tue, 25 Feb 2003 09:20:52 -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 h1PED36N017367 for ; Tue, 25 Feb 2003 06:13:03 -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 h1PED2vQ003232 for ; Tue, 25 Feb 2003 06:13:02 -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 h1PECgAV003258 for ; Tue, 25 Feb 2003 06:12:48 -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 h1PDuxm06324 for ; Tue, 25 Feb 2003 15:56:59 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Feb 2003 15:53:49 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 15:53:49 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 15:53:48 +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: Addr in INIT or INIT ACK Date: Tue, 25 Feb 2003 15:53:48 +0200 Message-ID: Thread-Topic: Addr in INIT or INIT ACK Thread-Index: AcLc097DeIT5pYa1RQK5YaBIaAlIRAAADN8g From: To: Cc: , X-OriginalArrivalTime: 25 Feb 2003 13:53:48.0643 (UTC) FILETIME=[52489B30:01C2DCD5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA01757 > > Hi Vijay and Brian! > > > > Well, actually, the section doesn't specify exactly > what's trying to > > solve... if you aren't aware in advance about what it > is trying to > > fix, it is difficult to understand why one should do that... > > > > But the answer is very easy. The point is that the INIT > ACK must be > > sent to the source address from which the INIT chunk > came. However, it > > can be sent from any of the available source addresses > at the INIT ACK > > sender. Thus, if the INIT ACK receiver doesn't > recognize the source > > address doesn't take a look inside, it can wrongly > discard the chunk, > > not establishing the association... :-( > > One can use the verification tag and destination address of > the INIT ACK and > need not examine the source address or source address list. I think this has been discussed many times... You are not supposed to use the VT to identify associations... This is not how the protocol works... > > About the INIT... It is a little bit trickier, but > there are also some > > special cases... Imagine the peer restarts and sends > you an INIT, > > including (some of) the previous address as parameters, > but using a > > new address as the source address (or instead of this, > you simply have > > an attacker sending you such an INIT chunk). In this > case you should > > in fact send back and ABORT with the 'Restart of an > association with > > new addresses' cause error. You won't be able to recognize this > > situation if you don't go through the addresses inside... :-/ > > Restart of an assoc... is only sent when addresses are added, > not when the > INIT is sent to a different address already belonging to the existing > association. I was meaning the source address of the INIT, not the destination... If you receive an INIT and you don't look inside the parameters, how do you know if the INIT comes from a new peer, of it is a peer with whom you already have an association but it is adding addresses (to start with the source address of the INIT)? Or, if a peer is restarting, how do you know it is simply restarting or it is also adding addresses? You have to look inside the INIT... > Also, IG section 2.6 is quite clear the the INIT addresses need to be > examined for new addresses. There seems little reason to > vaguely repeat > this in 2.18. One section is for "special" cases (duplicate packets), while the other is for normal ones... Maybe they could be merged... :-/ BR Iván Arias Rodríguez > --brian > > > > > I think that we could modify a little section 2.18.3. > Currently it says: > > > > 2.18.3 Solution description > > > > This new text clearly specifies to an implementor the > need to look > > within the INIT or INIT-ACK. Any implementation that does not do > > this, may not be able to establish associations in certain > > circumstances. > > > > > > Could it be better something like...?: > > > > This new text clearly specifies to an implementor the > need to look > > within the INIT or INIT ACK. Any implementation that does not do > > this, may for example not be able to recognize an INIT > chunk coming > > from an already established association that adds new addresses > > (see section 2.6), or an incoming INIT ACK chunk sent > from a source > > address different to the destination address used to > send the INIT > > chunk. > > > > > > How does it sound? > > > > BR Iván Arias Rodríguez > > > > > -----Original Message----- > > > From: ext Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > Sent: Tuesday, 25 February, 2003 11:41 > > > To: Vijay Kumar Choudhary > > > Cc: sctp-impl@external.cisco.com > > > Subject: Re: Addr in INIT or INIT ACK > > > > > > > > > Vijay, > > > > > > The section doesn't really way what problem > > > it is trying to solve, does it? > > > > > > --brian > > > > > > On Tue, 25 Feb 2003, Vijay Kumar Choudhary wrote: > > > > > > > Hi All, > > > > In the sctp-imp-guide version 7, the following paragraph > > > is there .. > > > > > > > > 2.18.3 Solution description > > > > This new text clearly specifies to an implementor the > > > need to look > > > > within the INIT or INIT-ACK. Any implementation > that does not do > > > > this, may not be able to establish associations in certain > > > > circumstances. > > > > > > > > I want to know the circumstances in the which the > > > association will not be > > > > established. > > > > > > > > Regards, > > > > Vijay > > > > > > -- > > > 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-1.cisco.com Tue Feb 25 09:29:48 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 JAA01920 for ; Tue, 25 Feb 2003 09:29: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-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1PEHS56026655 for ; Tue, 25 Feb 2003 06:17:28 -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 h1PEGt72014771 for ; Tue, 25 Feb 2003 06:16:56 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id h1PEHTWT006004 for ; Tue, 25 Feb 2003 06:17:32 -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 h1PEBmm18640 for ; Tue, 25 Feb 2003 16:11:48 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Feb 2003 16:08:41 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 16:08:41 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 16:08:40 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 16:08:40 +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, 25 Feb 2003 16:08:39 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLc07q67zYJySICQj60MVRlF+SZ0wAAcLcA From: To: , Cc: X-OriginalArrivalTime: 25 Feb 2003 14:08:40.0335 (UTC) FILETIME=[65C601F0:01C2DCD7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA01920 Hei! > Iván, > > But I don't have to look in either the INIT or INIT-ACK to determine > this. All I have to do is look in the cookie of the COOKIE-ECHO. Why looking in the COOKIE ECHO and not in the INIT directly? Don't you save time if you identify this situation earlier? > (For the second INIT ACK below, the verification tag gives away > the establishing association and a second COOKIE-ECHO can be > avoided without looking at the address list.) If you don't pay attention to the addresses inside the first INIT ACK, then you send the COOKIE ECHO and you save in your TCB the information about those addresses. When the second INIT ACK comes, you do the same... Depending how you have coded your implementation, you will either take that second INIT ACK as going to the first association, or to the second... If you take it as going to the first, you will discard it... otherwise you will create another association (still pending the receipt of the COOKIE ACK)... I don't see how taking a look to the parameters in the INIT/INIT ACK can hurt... :-/ You will have to do it sooner or later in any case... And most probably you can think about more harmful situations... > So that doesn't really explain the section to me... > > Also the section in the IG implies that associations will fail to be > formed that would otherwise be formed (not that multiple associations > will be attempted to be formed and could fail in one way instead of > another). Sometimes you cannot form the association, sometimes you have some other kind of problems... That's why I suggested the change... But that's in the other thread of mails... BR Iván Arias Rodríguez > --brian > > On Tue, 25 Feb 2003, Vijay Kumar Choudhary wrote: > > > Hi Ivan, > > Thanx for ur reply !!!! Now i got it. > > > > Regards, > > Vijay > > > > > > -------Original Message------- > > From: Ivan.Arias-Rodriguez@nokia.com > > Date: Tuesday, February 25, 2003 10:00:39 PM > > To: vijay@india.mercurykr.com; sctp-impl@external.cisco.com > > Subject: RE: Matching addresses in INIT and INIT ACK > > Hi Vijay! > > See my comment below... > > > Hi All, > > > In the sctp imp guide, a new point is added > > > > > > New text: Section 5.1.2 > > > > > > 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 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... > > > What will happen if i will not match the addresses, which are > > > contained in > > > the INIT or INIT ACK ? > > See above. > > BR Iván Arias Rodríguez > > > Regards, > > > Vijay > > > > > -- > 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 Tue Feb 25 09:48:26 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 JAA02282 for ; Tue, 25 Feb 2003 09:48:25 -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 h1PEbo6N002844 for ; Tue, 25 Feb 2003 06:37:50 -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 h1PEbILi027301 for ; Tue, 25 Feb 2003 06:37:18 -0800 (PST) Received: from gw.openss7.com (IDENT:GbnIZrMOQXpRfJ3ObmEUjadvWMqN1N/g@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1PEbWAV013460 for ; Tue, 25 Feb 2003 06:37:37 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:/Ezo/dyGn5+fjheP2cQr9Al2NiR8Pn9m@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1PEXKD22863; Tue, 25 Feb 2003 07:33:20 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1PEXK017005; Tue, 25 Feb 2003 07:33:20 -0700 Date: Tue, 25 Feb 2003 07:33:20 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: vijay@india.mercurykr.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030225073320.A16811@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, Feb 25, 2003 at 04:08:39PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Tue, 25 Feb 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Hei! > > > Iván, > > > > But I don't have to look in either the INIT or INIT-ACK to determine > > this. All I have to do is look in the cookie of the COOKIE-ECHO. > > Why looking in the COOKIE ECHO and not in the INIT directly? Don't you > save time if you identify this situation earlier? Saving time is implementation specific thing. Time can be saved (and security improved) by not trusting anything until verified with a cookie. > > > (For the second INIT ACK below, the verification tag gives away > > the establishing association and a second COOKIE-ECHO can be > > avoided without looking at the address list.) > > If you don't pay attention to the addresses inside the first INIT ACK, > then you send the COOKIE ECHO and you save in your TCB the information > about those addresses. When the second INIT ACK comes, you do the > same... Depending how you have coded your implementation, you will > either take that second INIT ACK as going to the first association, or > to the second... If you take it as going to the first, you will > discard it... otherwise you will create another association (still > pending the receipt of the COOKIE ACK)... > > I don't see how taking a look to the parameters in the INIT/INIT ACK > can hurt... :-/ You will have to do it sooner or later in any case... > > And most probably you can think about more harmful situations... I was considering a resent INIT ACK, because the case you gave is not possible on our implementation. (A user cannot establish two associations in such a manner: the second attempt will be refused and no INIT sent.) > > > So that doesn't really explain the section to me... > > > > Also the section in the IG implies that associations will fail to be > > formed that would otherwise be formed (not that multiple associations > > will be attempted to be formed and could fail in one way instead of > > another). > > Sometimes you cannot form the association, sometimes you have some > other kind of problems... That's why I suggested the change... But > that's in the other thread of mails... The thread does not cite a case where an association will not be formed that would otherwise be formed if the list was examined. --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 Feb 25 10:27:03 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 KAA03139 for ; Tue, 25 Feb 2003 10:27:02 -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 h1PFGX56003130; Tue, 25 Feb 2003 07:16: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 ADT68454; Tue, 25 Feb 2003 07:16:32 -0800 (PST) Message-ID: <3E5B88D0.5000708@cisco.com> Date: Tue, 25 Feb 2003 09:16:32 -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, vijay@india.mercurykr.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030225073320.A16811@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 Tue, 25 Feb 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > >> Hei! >> >> >> >>>Iván, >>> >>>But I don't have to look in either the INIT or INIT-ACK to determine >>>this. All I have to do is look in the cookie of the COOKIE-ECHO. >>> >>> >> Why looking in the COOKIE ECHO and not in the INIT directly? Don't you >> save time if you identify this situation earlier? >> >> > >Saving time is implementation specific thing. Time can be saved (and >security improved) by not trusting anything until verified with a cookie. > > I do not see how putting info you get from a INIT into a COOKIE and then waiting for the COOKIE to come back to check this same information improves security? After all it should be the same information, right? > > >>>(For the second INIT ACK below, the verification tag gives away >>>the establishing association and a second COOKIE-ECHO can be >>>avoided without looking at the address list.) >>> >>> >> If you don't pay attention to the addresses inside the first INIT ACK, >> then you send the COOKIE ECHO and you save in your TCB the information >> about those addresses. When the second INIT ACK comes, you do the >> same... Depending how you have coded your implementation, you will >> either take that second INIT ACK as going to the first association, or >> to the second... If you take it as going to the first, you will >> discard it... otherwise you will create another association (still >> pending the receipt of the COOKIE ACK)... >> >> I don't see how taking a look to the parameters in the INIT/INIT ACK >> can hurt... :-/ You will have to do it sooner or later in any case... >> >> And most probably you can think about more harmful situations... >> >> > >I was considering a resent INIT ACK, because the case you gave is not >possible on our implementation. (A user cannot establish two associations >in such a manner: the second attempt will be refused and no INIT sent.) > > > >>>So that doesn't really explain the section to me... >>> >>>Also the section in the IG implies that associations will fail to be >>>formed that would otherwise be formed (not that multiple associations >>>will be attempted to be formed and could fail in one way instead of >>>another). >>> >>> >> Sometimes you cannot form the association, sometimes you have some >> other kind of problems... That's why I suggested the change... But >> that's in the other thread of mails... >> >> > >The thread does not cite a case where an association will not be formed that >would otherwise be formed if the list was examined. > Here is one for this thread: E-A E-Z IP-A/IP-B IP-X/IP-Z INIT (ipsrc=IP-A,ipdst=IP-X)[IPA/IPB]------------------------> <--------------------INIT-ACK(ipsrc=IP-Z, ipdst=IP-A)[IPX,IPZ]--- Now when the INIT-ACK arrives if you solely look at the ipsrc address you will not find the association since at the time of startup you did not know IPZ existed.. all you knew about was IPX. Why would E-Z send a INIT-ACK sourced from IP-X? Well it could be the prefered route 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-msg-core-1.cisco.com Tue Feb 25 10:54:16 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 KAA04280 for ; Tue, 25 Feb 2003 10:54:15 -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 h1PFk856022561; Tue, 25 Feb 2003 07:46: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 ADT70604; Tue, 25 Feb 2003 07:46:08 -0800 (PST) Message-ID: <3E5B8FBF.9060908@cisco.com> Date: Tue, 25 Feb 2003 09:46:07 -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, vijay@india.mercurykr.com Subject: Re: Addr in INIT or INIT ACK References: <20030225070518.E15879@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: > > >> >> > >Where is it written that "You are not supposed to use the VT to identify >associations..." ??? As it is neither forbidden nor counter-recommended in >the RFC it is permitted. > >And in situations like this it is particularly efficient. > >--brian > > > Well, if you look at the key terms... RFC2960 states: " o SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time. " Note that Verification Tags are considered state... and the transport addresses can be used to uniquely identify an association... the V-Tags were never intended to be used as a method to identify the association (thats why you do not find it mentioned above).... you may be able to use it has an optimization (depending on your implementation and how you assign v-tags of course)...but this is your implementation details... 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-2.cisco.com Tue Feb 25 11:05:54 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 LAA04680 for ; Tue, 25 Feb 2003 11:05:53 -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 h1PFtuHK026428 for ; Tue, 25 Feb 2003 07:55:56 -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 h1PFuC5P012867 for ; Tue, 25 Feb 2003 07:56:12 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1PFtqAV014962 for ; Tue, 25 Feb 2003 07:55:56 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1PFZm211904 for ; Tue, 25 Feb 2003 17:35:48 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Feb 2003 17:37:02 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 17:37:01 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 17:37:01 +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, 25 Feb 2003 17:37:00 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLc239DiX5JyMkSTR2aBPSEoPNCygAB14yg From: To: Cc: , X-OriginalArrivalTime: 25 Feb 2003 15:37:01.0274 (UTC) FILETIME=[BD611BA0:01C2DCE3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA04680 Brian, > Ivan.Arias-Rodriguez, > > On Tue, 25 Feb 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > Hei! > > > > > Iván, > > > > > > But I don't have to look in either the INIT or INIT-ACK > to determine > > > this. All I have to do is look in the cookie of the COOKIE-ECHO. > > > > Why looking in the COOKIE ECHO and not in the INIT > directly? Don't you > > save time if you identify this situation earlier? > > Saving time is implementation specific thing. Time can be saved (and > security improved) by not trusting anything until verified > with a cookie. I think you save time not creating, sending and reading the COOKIE ECHO... You will always take a look to the parameters in the INIT, why leaving it for later? I don't get it... :-/ And you won't trust anything that has not been verified with a cookie... You simply anticipate the facts... > > > (For the second INIT ACK below, the verification tag gives away > > > the establishing association and a second COOKIE-ECHO can be > > > avoided without looking at the address list.) > > > > If you don't pay attention to the addresses inside the > first INIT ACK, > > then you send the COOKIE ECHO and you save in your TCB > the information > > about those addresses. When the second INIT ACK comes, > you do the > > same... Depending how you have coded your > implementation, you will > > either take that second INIT ACK as going to the first > association, or > > to the second... If you take it as going to the first, you will > > discard it... otherwise you will create another > association (still > > pending the receipt of the COOKIE ACK)... > > > > I don't see how taking a look to the parameters in the > INIT/INIT ACK > > can hurt... :-/ You will have to do it sooner or later > in any case... > > > > And most probably you can think about more harmful situations... > > I was considering a resent INIT ACK, because the case you gave is not > possible on our implementation. (A user cannot establish two > associations > in such a manner: the second attempt will be refused and no > INIT sent.) Why? If you haven't created the first association, the user can still ask for the second one. It (nor the SCTP implementation) doesn't have to know that both addresses belong to the same host until the INIT ACK is received and processed... This was just an example, I'm not saying that it is not a corner case... > > > So that doesn't really explain the section to me... > > > > > > Also the section in the IG implies that associations will > fail to be > > > formed that would otherwise be formed (not that multiple > associations > > > will be attempted to be formed and could fail in one way > instead of > > > another). > > > > Sometimes you cannot form the association, sometimes > you have some > > other kind of problems... That's why I suggested the > change... But > > that's in the other thread of mails... > > The thread does not cite a case where an association will not > be formed that > would otherwise be formed if the list was examined. I spoke about one such case: the INIT receiver sends the INIT ACK from a source different than the destination of the INIT... 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-msg-core-2.cisco.com Tue Feb 25 11:07:50 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 LAA04719 for ; Tue, 25 Feb 2003 11:07:49 -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 h1PFweHK028127 for ; Tue, 25 Feb 2003 07:58:40 -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 h1PFwOqJ023427 for ; Tue, 25 Feb 2003 07:58:24 -0800 (PST) Received: from gw.openss7.com (IDENT:IdClA6bJ3xMu6bvR7oKMWoFbbCMlWRRY@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1PFu5T6015945 for ; Tue, 25 Feb 2003 07:56:06 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:b6lGYA6S/0PRbkPwoG2bwVDcpQEJ4fpK@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1PFqwD24423; Tue, 25 Feb 2003 08:52:58 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1PFqw418702; Tue, 25 Feb 2003 08:52:58 -0700 Date: Tue, 25 Feb 2003 08:52:58 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, vijay@india.mercurykr.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030225085258.A18312@openss7.org> Reply-To: bidulock@openss7.org References: <20030225073320.A16811@openss7.org> <3E5B88D0.5000708@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: <3E5B88D0.5000708@cisco.com>; from rrs@cisco.com on Tue, Feb 25, 2003 at 09:16:32AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Tue, 25 Feb 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >Ivan.Arias-Rodriguez, > > > >On Tue, 25 Feb 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > > > > > >> Hei! > >> > >> > >> > >>>Iván, > >>> > >>>But I don't have to look in either the INIT or INIT-ACK to determine > >>>this. All I have to do is look in the cookie of the COOKIE-ECHO. > >>> > >>> > >> Why looking in the COOKIE ECHO and not in the INIT directly? Don't you > >> save time if you identify this situation earlier? > >> > >> > > > >Saving time is implementation specific thing. Time can be saved (and > >security improved) by not trusting anything until verified with a cookie. > > > > > I do not see how putting info you get from a INIT into a COOKIE and then > waiting for the COOKIE to come back to check this same information > improves security? After all it should be the same information, right? Because the all of the source addresses of an INIT are suspect until verified. > > > > > > >>>(For the second INIT ACK below, the verification tag gives away > >>>the establishing association and a second COOKIE-ECHO can be > >>>avoided without looking at the address list.) > >>> > >>> > >> If you don't pay attention to the addresses inside the first INIT ACK, > >> then you send the COOKIE ECHO and you save in your TCB the information > >> about those addresses. When the second INIT ACK comes, you do the > >> same... Depending how you have coded your implementation, you will > >> either take that second INIT ACK as going to the first association, or > >> to the second... If you take it as going to the first, you will > >> discard it... otherwise you will create another association (still > >> pending the receipt of the COOKIE ACK)... > >> > >> I don't see how taking a look to the parameters in the INIT/INIT ACK > >> can hurt... :-/ You will have to do it sooner or later in any case... > >> > >> And most probably you can think about more harmful situations... > >> > >> > > > >I was considering a resent INIT ACK, because the case you gave is not > >possible on our implementation. (A user cannot establish two associations > >in such a manner: the second attempt will be refused and no INIT sent.) > > > > > > > >>>So that doesn't really explain the section to me... > >>> > >>>Also the section in the IG implies that associations will fail to be > >>>formed that would otherwise be formed (not that multiple associations > >>>will be attempted to be formed and could fail in one way instead of > >>>another). > >>> > >>> > >> Sometimes you cannot form the association, sometimes you have some > >> other kind of problems... That's why I suggested the change... But > >> that's in the other thread of mails... > >> > >> > > > >The thread does not cite a case where an association will not be formed that > >would otherwise be formed if the list was examined. > > > Here is one for this thread: > E-A > E-Z > IP-A/IP-B > IP-X/IP-Z > > INIT (ipsrc=IP-A,ipdst=IP-X)[IPA/IPB]------------------------> > <--------------------INIT-ACK(ipsrc=IP-Z, ipdst=IP-A)[IPX,IPZ]--- > > Now when the INIT-ACK arrives if you solely look at the ipsrc address > you will not find the association since at the time of startup you > did not know IPZ existed.. all you knew about was IPX. > > Why would E-Z send a INIT-ACK sourced from IP-X? Well it > could be the prefered route out.. One can use the destination address (IP-A) and port number to find the association. As one does not need to look at the source address at all to find the association, digging in the INIT ACK at this point is a waste of time. The association is found using IP-A and port number and then verified using VT, or it can simply be found with VT and checked for IP-A and port number (the order makes no difference). Only once the association is found and the VT and destination address/port are verified, and the state of the association is correct for processing an INIT-ACK does the implementation need to deal with source addresses and lists. I use VT because it has better hash characteristics and is faster. Finding the association with source addresses is a waste of time for INIT-ACKs that will be discarded on VT mismatch or incorrect destination addresses (the MUST in 5.2 B), and therefore opens up the implementation to possible attacks (INIT-ACK flooding with long address lists, or out of range address list parameter lengths). So in this case, a recommendation to dig the address list before looking for the association is a poor one. Do you have another case where you think an association cannot be formed? --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 Feb 25 11:16:49 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 LAA05014 for ; Tue, 25 Feb 2003 11:16: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-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1PG2k56004874 for ; Tue, 25 Feb 2003 08:02:46 -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 h1PG2E29026449 for ; Tue, 25 Feb 2003 08:02:14 -0800 (PST) Received: from gw.openss7.com (IDENT:iCqYofPUftixS4jcHL1q+HC5dMJIVx8d@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id h1PG2iWT017447 for ; Tue, 25 Feb 2003 08:02:50 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:vhySY6+UOblhmP/5nn7lecQTfF4wquop@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1PFwRD24495; Tue, 25 Feb 2003 08:58:27 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1PFwRc18793; Tue, 25 Feb 2003 08:58:27 -0700 Date: Tue, 25 Feb 2003 08:58:27 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: vijay@india.mercurykr.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030225085827.B18312@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, Feb 25, 2003 at 05:37:00PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Tue, 25 Feb 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Brian, > > > Ivan.Arias-Rodriguez, > > > > On Tue, 25 Feb 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > > > > > Hei! > > > > > > > Iván, > > > > > > > > But I don't have to look in either the INIT or INIT-ACK > > to determine > > > > this. All I have to do is look in the cookie of the COOKIE-ECHO. > > > > > > Why looking in the COOKIE ECHO and not in the INIT > > directly? Don't you > > > save time if you identify this situation earlier? > > > > Saving time is implementation specific thing. Time can be saved (and > > security improved) by not trusting anything until verified > > with a cookie. > > I think you save time not creating, sending and reading the COOKIE > ECHO... You will always take a look to the parameters in the INIT, why > leaving it for later? I don't get it... :-/ No need to look at them, copy them directly to the cookie. > And you won't trust anything that has not been verified with a > cookie... You simply anticipate the facts... The facts may be different than you anticipate, particularly when under attack. > > > > > (For the second INIT ACK below, the verification tag gives away > > > > the establishing association and a second COOKIE-ECHO can be > > > > avoided without looking at the address list.) > > > > > > If you don't pay attention to the addresses inside the > > first INIT ACK, > > > then you send the COOKIE ECHO and you save in your TCB > > the information > > > about those addresses. When the second INIT ACK comes, > > you do the > > > same... Depending how you have coded your > > implementation, you will > > > either take that second INIT ACK as going to the first > > association, or > > > to the second... If you take it as going to the first, you will > > > discard it... otherwise you will create another > > association (still > > > pending the receipt of the COOKIE ACK)... > > > > > > I don't see how taking a look to the parameters in the > > INIT/INIT ACK > > > can hurt... :-/ You will have to do it sooner or later > > in any case... > > > > > > And most probably you can think about more harmful situations... > > > > I was considering a resent INIT ACK, because the case you gave is not > > possible on our implementation. (A user cannot establish two > > associations > > in such a manner: the second attempt will be refused and no > > INIT sent.) > > Why? If you haven't created the first association, the user can still > ask for the second one. It (nor the SCTP implementation) doesn't have > to know that both addresses belong to the same host until the INIT ACK > is received and processed... This was just an example, I'm not saying > that it is not a corner case... We provide an address list to connect() which contains all the addresses of the peer. The second such attempt fails. > > > > > So that doesn't really explain the section to me... > > > > > > > > Also the section in the IG implies that associations will > > fail to be > > > > formed that would otherwise be formed (not that multiple > > associations > > > > will be attempted to be formed and could fail in one way > > instead of > > > > another). > > > > > > Sometimes you cannot form the association, sometimes > > you have some > > > other kind of problems... That's why I suggested the > > change... But > > > that's in the other thread of mails... > > > > The thread does not cite a case where an association will not > > be formed that > > would otherwise be formed if the list was examined. > > I spoke about one such case: the INIT receiver sends the INIT ACK from > a source different than the destination of the INIT... In that example the association is supposed to fail (ABORT Restart with new address...). Do you have one where the association is supposed to form but does not because the address list is not searched? --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 Feb 25 11:22:41 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 LAA05242 for ; Tue, 25 Feb 2003 11:22:39 -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 h1PGCW56012044; Tue, 25 Feb 2003 08:12: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 ADT72583; Tue, 25 Feb 2003 08:12:30 -0800 (PST) Message-ID: <3E5B95EE.5020106@cisco.com> Date: Tue, 25 Feb 2003 10:12: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: bidulock@openss7.org CC: Ivan.Arias-Rodriguez@nokia.com, vijay@india.mercurykr.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK References: <20030225073320.A16811@openss7.org> <3E5B88D0.5000708@cisco.com> <20030225085258.A18312@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: >>I do not see how putting info you get from a INIT into a COOKIE and then >>waiting for the COOKIE to come back to check this same information >>improves security? After all it should be the same information, right? >> >> > >Because the all of the source addresses of an INIT are suspect until >verified. > > Ok, I can buy that.. but how does this: ---Src-IP-A-----INIT(IPA,IPB,IPC,IPD)--------->Dst-IP-Z Dst-IP-A<------------------INIT-ACK(IPZ,IPX,IPQ)----Src-IP-Z Src-IP-A------------------CookieEcho()------------------>Dst-IP-Z Make things more secure? You still have the same information and you still have not verified anything about IPB,IPC or IPD... > > >>> >>> >>> >>> >>>>>(For the second INIT ACK below, the verification tag gives away >>>>>the establishing association and a second COOKIE-ECHO can be >>>>>avoided without looking at the address list.) >>>>> >>>>> >>>>> >>>>> >>>> If you don't pay attention to the addresses inside the first INIT ACK, >>>> then you send the COOKIE ECHO and you save in your TCB the information >>>> about those addresses. When the second INIT ACK comes, you do the >>>> same... Depending how you have coded your implementation, you will >>>> either take that second INIT ACK as going to the first association, or >>>> to the second... If you take it as going to the first, you will >>>> discard it... otherwise you will create another association (still >>>> pending the receipt of the COOKIE ACK)... >>>> >>>> I don't see how taking a look to the parameters in the INIT/INIT ACK >>>> can hurt... :-/ You will have to do it sooner or later in any case... >>>> >>>> And most probably you can think about more harmful situations... >>>> >>>> >>>> >>>> >>>I was considering a resent INIT ACK, because the case you gave is not >>>possible on our implementation. (A user cannot establish two associations >>>in such a manner: the second attempt will be refused and no INIT sent.) >>> >>> >>> >>> >>> >>>>>So that doesn't really explain the section to me... >>>>> >>>>>Also the section in the IG implies that associations will fail to be >>>>>formed that would otherwise be formed (not that multiple associations >>>>>will be attempted to be formed and could fail in one way instead of >>>>>another). >>>>> >>>>> >>>>> >>>>> >>>> Sometimes you cannot form the association, sometimes you have some >>>> other kind of problems... That's why I suggested the change... But >>>> that's in the other thread of mails... >>>> >>>> >>>> >>>> >>>The thread does not cite a case where an association will not be formed that >>>would otherwise be formed if the list was examined. >>> >>> >>> >>Here is one for this thread: >> E-A >> E-Z >>IP-A/IP-B >> IP-X/IP-Z >> >>INIT (ipsrc=IP-A,ipdst=IP-X)[IPA/IPB]------------------------> >> <--------------------INIT-ACK(ipsrc=IP-Z, ipdst=IP-A)[IPX,IPZ]--- >> >>Now when the INIT-ACK arrives if you solely look at the ipsrc address >>you will not find the association since at the time of startup you >>did not know IPZ existed.. all you knew about was IPX. >> >>Why would E-Z send a INIT-ACK sourced from IP-X? Well it >>could be the prefered route out.. >> >> > >One can use the destination address (IP-A) and port number to find the >association. As one does not need to look at the source address at all >to find the association, digging in the INIT ACK at this point is a waste >of time. The association is found using IP-A and port number and then > So, lets see, if E-A sent out 100 INIT's to different endpoints .. setting up 100 associations, how can we depend on IP-A and Port to find the association? Just the IP-A and Port will not cut it.. you need to look at the source address and port as well.. which means you must dig through the INIT-ACK to find IP-X... >verified using VT, or it can simply be found with VT and checked for IP-A >and port number (the order makes no difference). > The V-Tag is only an optimization that you happen to be using.. it is not one of the things that makes a association unqiue.... not by protocol design.. as I said, one can implement it this way but it is NOT part of the spec... >Only once the association >is found and the VT and destination address/port are verified, and the >state of the association is correct for processing an INIT-ACK does the >implementation need to deal with source addresses and lists. > > I think you are discussing your particular design details.. which is specific to your implementation... >I use VT because it has better hash characteristics and is faster. > > And that is fine.. but it is NOT, according to RFC2960, what uniquely identifies an association.... >Finding the association with source addresses is a waste of time for >INIT-ACKs that will be discarded on VT mismatch or incorrect destination >addresses (the MUST in 5.2 B), and therefore opens up the implementation >to possible attacks (INIT-ACK flooding with long address lists, or out >of range address list parameter lengths). > > I can flood you with INIT-ACK's without long lists and still get the same effect... For that matter, UDP-Flooding is more effective :-0 >So in this case, a recommendation to dig the address list before looking >for the association is a poor one. > > This is only based on your design and is NOT part of the protocol specification. And in my above example, if you are sending out 100's of INIT's you can end up in a situation where you can't form the association.. This happened in several bake-offs... R >Do you have another case where you think an association cannot be formed? > >--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 Tue Feb 25 13:11:01 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 NAA09071 for ; Tue, 25 Feb 2003 13:10:59 -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 h1PI1cP7002838 for ; Tue, 25 Feb 2003 10:01:38 -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 h1PI1kJE022515 for ; Tue, 25 Feb 2003 10:01:50 -0800 (PST) Received: from gw.openss7.com (IDENT:afaYR7Fh4SHmmzN2q+m4w1Dv7nuVM0rx@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1PI1EAV008006 for ; Tue, 25 Feb 2003 10:01:25 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:dqTfo4rB7dcvDvOeRyOtzj385Q7eG7cg@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1PHuFD26320; Tue, 25 Feb 2003 10:56:15 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1PHuD422493; Tue, 25 Feb 2003 10:56:13 -0700 Date: Tue, 25 Feb 2003 10:56:13 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Ivan.Arias-Rodriguez@nokia.com, vijay@india.mercurykr.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030225105613.A22068@openss7.org> Reply-To: bidulock@openss7.org References: <20030225073320.A16811@openss7.org> <3E5B88D0.5000708@cisco.com> <20030225085258.A18312@openss7.org> <3E5B95EE.5020106@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: <3E5B95EE.5020106@cisco.com>; from rrs@cisco.com on Tue, Feb 25, 2003 at 10:12:30AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Randall, On Tue, 25 Feb 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > >>I do not see how putting info you get from a INIT into a COOKIE and then > >>waiting for the COOKIE to come back to check this same information > >>improves security? After all it should be the same information, right? > >> > >> > > > >Because the all of the source addresses of an INIT are suspect until > >verified. > > > > > Ok, I can buy that.. but how does this: > > ---Src-IP-A-----INIT(IPA,IPB,IPC,IPD)--------->Dst-IP-Z > Dst-IP-A<------------------INIT-ACK(IPZ,IPX,IPQ)----Src-IP-Z > Src-IP-A------------------CookieEcho()------------------>Dst-IP-Z > > Make things more secure? You still have the same > information and you still have not verified anything about > IPB,IPC or IPD... You have verified the hash in the cookie so you know that the sender of the cookie was the sender of the INIT. > > > > > > > > >>> > >>> > >>> > >>> > >>>>>(For the second INIT ACK below, the verification tag gives away > >>>>>the establishing association and a second COOKIE-ECHO can be > >>>>>avoided without looking at the address list.) > >>>>> > >>>>> > >>>>> > >>>>> > >>>> If you don't pay attention to the addresses inside the first INIT ACK, > >>>> then you send the COOKIE ECHO and you save in your TCB the information > >>>> about those addresses. When the second INIT ACK comes, you do the > >>>> same... Depending how you have coded your implementation, you will > >>>> either take that second INIT ACK as going to the first association, or > >>>> to the second... If you take it as going to the first, you will > >>>> discard it... otherwise you will create another association (still > >>>> pending the receipt of the COOKIE ACK)... > >>>> > >>>> I don't see how taking a look to the parameters in the INIT/INIT ACK > >>>> can hurt... :-/ You will have to do it sooner or later in any case... > >>>> > >>>> And most probably you can think about more harmful situations... > >>>> > >>>> > >>>> > >>>> > >>>I was considering a resent INIT ACK, because the case you gave is not > >>>possible on our implementation. (A user cannot establish two associations > >>>in such a manner: the second attempt will be refused and no INIT sent.) > >>> > >>> > >>> > >>> > >>> > >>>>>So that doesn't really explain the section to me... > >>>>> > >>>>>Also the section in the IG implies that associations will fail to be > >>>>>formed that would otherwise be formed (not that multiple associations > >>>>>will be attempted to be formed and could fail in one way instead of > >>>>>another). > >>>>> > >>>>> > >>>>> > >>>>> > >>>> Sometimes you cannot form the association, sometimes you have some > >>>> other kind of problems... That's why I suggested the change... But > >>>> that's in the other thread of mails... > >>>> > >>>> > >>>> > >>>> > >>>The thread does not cite a case where an association will not be formed that > >>>would otherwise be formed if the list was examined. > >>> > >>> > >>> > >>Here is one for this thread: > >> E-A > >> E-Z > >>IP-A/IP-B > >> IP-X/IP-Z > >> > >>INIT (ipsrc=IP-A,ipdst=IP-X)[IPA/IPB]------------------------> > >> <--------------------INIT-ACK(ipsrc=IP-Z, ipdst=IP-A)[IPX,IPZ]--- > >> > >>Now when the INIT-ACK arrives if you solely look at the ipsrc address > >>you will not find the association since at the time of startup you > >>did not know IPZ existed.. all you knew about was IPX. > >> > >>Why would E-Z send a INIT-ACK sourced from IP-X? Well it > >>could be the prefered route out.. > >> > >> > > > >One can use the destination address (IP-A) and port number to find the > >association. As one does not need to look at the source address at all > >to find the association, digging in the INIT ACK at this point is a waste > >of time. The association is found using IP-A and port number and then > > > So, lets see, if E-A sent out 100 INIT's to different endpoints .. setting > up 100 associations, how can we depend on IP-A and Port to find the > association? Just the IP-A and Port will not cut it.. you need > to look at the source address and port as well.. which means > you must dig through the INIT-ACK to find IP-X... So use VT. > > > >verified using VT, or it can simply be found with VT and checked for IP-A > >and port number (the order makes no difference). > > > The V-Tag is only an optimization that you happen to be using.. it is > not one of the things that makes a association unqiue.... not by > protocol design.. as I said, one can implement it this way but it > is NOT part of the spec... But don't suppose to me I have to look (or even should) look in the list when I don't have to and can use more optimal approaches. > > >Only once the association > >is found and the VT and destination address/port are verified, and the > >state of the association is correct for processing an INIT-ACK does the > >implementation need to deal with source addresses and lists. > > > > > I think you are discussing your particular design details.. which is > specific to your implementation... And how associations are found is always implementation specific. One does not have to use the source address list, so don't suppose to say so. > > >I use VT because it has better hash characteristics and is faster. > > > > > And that is fine.. but it is NOT, according to RFC2960, what uniquely > identifies an association.... RFC2960 does not say that it does NOT identify an association: it just does not say that it does. So what? > > >Finding the association with source addresses is a waste of time for > >INIT-ACKs that will be discarded on VT mismatch or incorrect destination > >addresses (the MUST in 5.2 B), and therefore opens up the implementation > >to possible attacks (INIT-ACK flooding with long address lists, or out > >of range address list parameter lengths). > > > > > I can flood you with INIT-ACK's without long lists and still get the same > effect... For that matter, UDP-Flooding is more effective :-0 If you walk the list to find the association, that is simply not true. > > > >So in this case, a recommendation to dig the address list before looking > >for the association is a poor one. > > > > > This is only based on your design and is NOT part of the protocol > specification. > And in my above example, if you are sending out 100's of INIT's you can > end up in a situation where you can't form the association.. This happened > in several bake-offs... Simply generating a unique VT for each association (and init attempt) can resolve this without walking an address list to find the association. As this is indeed implementation dependent, I suggest it be left alone. It should be left completely at the discretion of the implementation. As long as only one assocation can exist between endpoints, how an implementation goes about enforcing that is internal to the implementation. > > R > > >Do you have another case where you think an association cannot be formed? Obviously you don't have a case where one must look in the source address list to form proper associations, just so that they can be failed in certain ways in corner cases. --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 Wed Feb 26 07:32:57 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 HAA02466 for ; Wed, 26 Feb 2003 07:32:56 -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 h1QCR256024529 for ; Wed, 26 Feb 2003 04:27:02 -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 h1QCQQwb021512 for ; Wed, 26 Feb 2003 04:26:26 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1QCQjAW009720 for ; Wed, 26 Feb 2003 04:26:51 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1QC6n224516 for ; Wed, 26 Feb 2003 14:06:49 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Feb 2003 14:08:03 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 14:08:03 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 14:08:02 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 14:08:02 +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, 26 Feb 2003 14:08:01 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLc514r8lb2ZC3GQQ6CxpmkGNSkewAmuJfw From: To: Cc: , X-OriginalArrivalTime: 26 Feb 2003 12:08:02.0356 (UTC) FILETIME=[B603CF40:01C2DD8F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA02466 Brian F. G. Bidulock, snip... > > I think you save time not creating, sending and reading > the COOKIE > > ECHO... You will always take a look to the parameters > in the INIT, why > > leaving it for later? I don't get it... :-/ > > No need to look at them, copy them directly to the cookie. Well... So the point is that if the attacker is using IP spoofing, forging its source address, you will never receive the COOKIE ECHO... This way you will save the time of checking all the addresses... that's right... If the attacker includes many addresses then that time could be long... However, producing the cookie also takes time, and if the number of addresses in the INIT was so big you might even have to fragment your IP packet and stuff... but surely this time is shorter... If the INIT sender is not an attacker then I think that checking the addresses already when receiving the INIT makes things faster... but I can accept that there will be more attackers than "special cases"... :-/ However, I think that the point of recognizing if the peer is known or not because of the address parameters is vital for the initialization collision scenario... If you don't check it I guess that the whole procedure simply doesn't work... however I haven't deeply checked it... :-/ Does it work, Brian? > > And you won't trust anything that has not been verified with a > > cookie... You simply anticipate the facts... > > The facts may be different than you anticipate, particularly > when under > attack. Ok, see above... snip... > > > I was considering a resent INIT ACK, because the case you > gave is not > > > possible on our implementation. (A user cannot establish two > > > associations > > > in such a manner: the second attempt will be refused and no > > > INIT sent.) > > > > Why? If you haven't created the first association, the > user can still > > ask for the second one. It (nor the SCTP > implementation) doesn't have > > to know that both addresses belong to the same host > until the INIT ACK > > is received and processed... This was just an example, > I'm not saying > > that it is not a corner case... > > We provide an address list to connect() which contains all > the addresses of > the peer. The second such attempt fails. Supposing you already know which are the addresses of the peer... which you don't know... > > > > > So that doesn't really explain the section to me... > > > > > > > > > > Also the section in the IG implies that associations will > > > fail to be > > > > > formed that would otherwise be formed (not that multiple > > > associations > > > > > will be attempted to be formed and could fail in one way > > > instead of > > > > > another). > > > > > > > > Sometimes you cannot form the association, sometimes > > > you have some > > > > other kind of problems... That's why I suggested the > > > change... But > > > > that's in the other thread of mails... > > > > > > The thread does not cite a case where an association will not > > > be formed that > > > would otherwise be formed if the list was examined. > > > > I spoke about one such case: the INIT receiver sends > the INIT ACK from > > a source different than the destination of the INIT... > > In that example the association is supposed to fail (ABORT > Restart with new > address...). Do you have one where the association is > supposed to form but > does not because the address list is not searched? Brian, please, this is the third time I have to repeat it... It seems that you are not reading what I write... :-0 Read above again, and my previous mail if necessary... or Randall's... I mean when the INIT ACK sends the chunk from a different source address than the destination address of the INIT chunk (which is the only peer address you know so far, I don't know how you manage to know them all in advance... if it is that easy, why exchanging them at all?)... In any case, I think that the need of checking the addresses of the incoming INIT ACK is out of comment... you have to update your TCB... If you don't, when do you do it? After receiving the COOKIE ACK? Why if it doesn't add any information at all? Besides, the COOKIE ACK could easily come from a different address than the one used to send the INIT chunk... :-/ 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-msg-core-3.cisco.com Wed Feb 26 07:48: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 HAA02742 for ; Wed, 26 Feb 2003 07:48:14 -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 h1QCeMP7018739 for ; Wed, 26 Feb 2003 04:40:22 -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 h1QCds4f019314 for ; Wed, 26 Feb 2003 04:39:54 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1QCdjAW015796 for ; Wed, 26 Feb 2003 04:39:46 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1QCcS220319 for ; Wed, 26 Feb 2003 14:38:28 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Feb 2003 14:39:43 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 14:39:43 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 14:39:42 +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, 26 Feb 2003 14:39:42 +0200 Message-ID: Thread-Topic: Matching addresses in INIT and INIT ACK Thread-Index: AcLc+AGz78eSVNOdRCCTAUjiONqpCgAmFzIA From: To: , Cc: , X-OriginalArrivalTime: 26 Feb 2003 12:39:42.0989 (UTC) FILETIME=[22E163D0:01C2DD94] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA02742 Only comments about the last part of Brian's mail... snip... > > This is only based on your design and is NOT part of the protocol > > specification. > > And in my above example, if you are sending out 100's of > INIT's you can > > end up in a situation where you can't form the > association.. This happened > > in several bake-offs... > > Simply generating a unique VT for each association (and init > attempt) can > resolve this without walking an address list to find the association. "Simply generating a unique VT for each association" might not be that easy either... I'm just guessing here... I'm just exposing an idea... don't blame me... :-) Since you cannot keep any information upon sending the INIT ACK, obviously you don't have any list of "used VTs"... Then I suppose that your VT generator takes some kind of counter as its seed, and uses and algorithm that given a 32 bit number (or less), produces another "random" 32 bit number, which is not produced by any other different number taken as the seed, i.e., two different seeds produce two different VTs... So the VTs are only unique if the used seeds are different... You have to keep somehow the state of which seeds have been used. And you have to do it in a way so this state doesn't use more memory than a fixed maximum (and small) quantity, no matter how many (and which) seeds are in use. The only easy way I can think about now, is a simple counter... :-/ If this is the case, won't this make easier for the attacker to guess your "rule" of producing VTs? That rule is reversible, so... I'm just thinking in loud voice... And I suppose that the way you assure that all those VTs are unique, is the fact that 2^32 is a very big number and you won't wrap it... Establishing an association every 10 ms will give you about one year and a half... One association every millisecond gives you less than two months... This numbers might be acceptable, especially taking into account that the associations shouldn't last long, but I don't know... :-/ After that time you cannot be sure that your VTs are unique... Unless, of course, all my suppositions were wrong... :-/ BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Feb 26 08:07:55 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 IAA03166 for ; Wed, 26 Feb 2003 08:07:53 -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 h1QCxb56009462 for ; Wed, 26 Feb 2003 04:59:37 -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 h1QCx1HK009213 for ; Wed, 26 Feb 2003 04:59:01 -0800 (PST) Received: from gw.openss7.com (IDENT:dumAgPG6/nATLquZgqzeHw18TjgHbcwY@gw.openss7.com [142.179.199.224]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id h1QCxdNY003185 for ; Wed, 26 Feb 2003 04:59:41 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:xYAZQfn2rA/hLFi1ctig2uAyC8M4uqs3@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1QCrTD11084; Wed, 26 Feb 2003 05:53:29 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1QCrTn14298; Wed, 26 Feb 2003 05:53:29 -0700 Date: Wed, 26 Feb 2003 05:53:29 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: vijay@india.mercurykr.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030226055329.J8776@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 Wed, Feb 26, 2003 at 02:08:01PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Wed, 26 Feb 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Brian F. G. Bidulock, > > snip... > > > > I think you save time not creating, sending and reading > > the COOKIE > > > ECHO... You will always take a look to the parameters > > in the INIT, why > > > leaving it for later? I don't get it... :-/ > > > > No need to look at them, copy them directly to the cookie. > > Well... So the point is that if the attacker is using IP spoofing, forging its source address, you will never receive the COOKIE ECHO... This way you will save the time of checking all the addresses... that's right... If the attacker includes many addresses then that time could be long... However, producing the cookie also takes time, and if the number of addresses in the INIT was so big you might even have to fragment your IP packet and stuff... but surely this time is shorter... > > If the INIT sender is not an attacker then I think that checking the addresses already when receiving the INIT makes things faster... but I can accept that there will be more attackers than "special cases"... :-/ > > However, I think that the point of recognizing if the peer is known or not because of the address parameters is vital for the initialization collision scenario... If you don't check it I guess that the whole procedure simply doesn't work... however I haven't deeply checked it... :-/ > > Does it work, Brian? > > > > And you won't trust anything that has not been verified with a > > > cookie... You simply anticipate the facts... > > > > The facts may be different than you anticipate, particularly > > when under > > attack. > > Ok, see above... > > snip... > > > > > I was considering a resent INIT ACK, because the case you > > gave is not > > > > possible on our implementation. (A user cannot establish two > > > > associations > > > > in such a manner: the second attempt will be refused and no > > > > INIT sent.) > > > > > > Why? If you haven't created the first association, the > > user can still > > > ask for the second one. It (nor the SCTP > > implementation) doesn't have > > > to know that both addresses belong to the same host > > until the INIT ACK > > > is received and processed... This was just an example, > > I'm not saying > > > that it is not a corner case... > > > > We provide an address list to connect() which contains all > > the addresses of > > the peer. The second such attempt fails. > > Supposing you already know which are the addresses of the peer... which you don't know... What makes you think an application can know one address and not know the others? > > > > > > > So that doesn't really explain the section to me... > > > > > > > > > > > > Also the section in the IG implies that associations will > > > > fail to be > > > > > > formed that would otherwise be formed (not that multiple > > > > associations > > > > > > will be attempted to be formed and could fail in one way > > > > instead of > > > > > > another). > > > > > > > > > > Sometimes you cannot form the association, sometimes > > > > you have some > > > > > other kind of problems... That's why I suggested the > > > > change... But > > > > > that's in the other thread of mails... > > > > > > > > The thread does not cite a case where an association will not > > > > be formed that > > > > would otherwise be formed if the list was examined. > > > > > > I spoke about one such case: the INIT receiver sends > > the INIT ACK from > > > a source different than the destination of the INIT... > > > > In that example the association is supposed to fail (ABORT > > Restart with new > > address...). Do you have one where the association is > > supposed to form but > > does not because the address list is not searched? > > Brian, please, this is the third time I have to repeat it... It seems > that you are not reading what I write... :-0 > > Read above again, and my previous mail if necessary... or Randall's... > I mean when the INIT ACK sends the chunk from a different source > address than the destination address of the INIT chunk (which is the > only peer address you know so far, I don't know how you manage to know > them all in advance... if it is that easy, why exchanging them at > all?)... As I replied to Randall, one doesn't need to examine to source addresses to identify the association. The verification tag, destination address and port are sufficient. I have no problems with a spec saying that one should watch out for such situations, or making requirements that such situations must result in an association, or that multiple associations must not be formed between the same transport addresses; but, I do have a problem if the spec tries to tell me what I have to do in an implementation to identify an association. And, yes, it is possible for the application to know the list in advance. So we have this requirement on one association between two transport addresses. And another requirement on no restarts with new (expanded) address lists. The requirements are there: don't suppose to tell me how I should satistfy them in implementation. You can tell me how I MAY satisfy them, or better, provide an example or note. But don't tell me I SHOULD look in the address list when I clearly don't have to. > > In any case, I think that the need of checking the addresses of the > incoming INIT ACK is out of comment... you have to update your TCB... > If you don't, when do you do it? After receiving the COOKIE ACK? Why > if it doesn't add any information at all? Besides, the COOKIE ACK > could easily come from a different address than the one used to send > the INIT chunk... :-/ No, it is possible in implementation not to check. We've been over this before, but, because of the way that static and dynamic port allocation is normally performed it is possible for the implementation to know a priori that no overlap can occur. Where dynamic port allocation is performed for the remote port, overlap can be avoided a priori by never assigning the same remote port. The same is true for local dynamic port assignment. The implementation can know a priori that no overlap will occur because it never assigns the same local port to more than one association. The same is true where both ports are dynamically assigned. The only case that might cause a problem would be where both local and remote ports are statically assigned, but there is no requirement on an implementation to support overlapping address sets on a static port pair and even in this case the application can know (and because it is a static port pair, should know) the addresses of the remote host that it is connecting to. So, an implemntation can easily know, a priori, that there is no possibilty of overlap in the received transport addresses in the INIT ACK. Certainly it can know if dynamic port assignment was performed on either the local or remote port number. No examination is necessary and they can simply be copied to the TCB without examination. The association can be identified by destination address and port from the packet and the verification tag (properly generated to be unique when the INIT was sent). --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 Wed Feb 26 08:35:11 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 IAA03956 for ; Wed, 26 Feb 2003 08:35: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-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1QDRtHK004359 for ; Wed, 26 Feb 2003 05:27:55 -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 h1QDSD69016835 for ; Wed, 26 Feb 2003 05:28:13 -0800 (PST) Received: from gw.openss7.com (IDENT:VZogIo3pG8UyMP6AEI8Z7HpP7cJPsUnk@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1QDQTT6007633 for ; Wed, 26 Feb 2003 05:26:30 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:LYyUnBugrLUwjLtpBZuwVE3/+VEf8z/9@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1QDNiD11528; Wed, 26 Feb 2003 06:23:44 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1QDNiY14810; Wed, 26 Feb 2003 06:23:44 -0700 Date: Wed, 26 Feb 2003 06:23:44 -0700 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: rrs@cisco.com, vijay@india.mercurykr.com, sctp-impl@external.cisco.com Subject: Re: Matching addresses in INIT and INIT ACK Message-ID: <20030226062344.K8776@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 Wed, Feb 26, 2003 at 02:39:42PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Wed, 26 Feb 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Only comments about the last part of Brian's mail... > > snip... > > > > This is only based on your design and is NOT part of the protocol > > > specification. > > > And in my above example, if you are sending out 100's of > > INIT's you can > > > end up in a situation where you can't form the > > association.. This happened > > > in several bake-offs... > > > > Simply generating a unique VT for each association (and init > > attempt) can > > resolve this without walking an address list to find the association. > > "Simply generating a unique VT for each association" might not be that easy either... > > I'm just guessing here... I'm just exposing an idea... don't blame me... :-) > > Since you cannot keep any information upon sending the INIT ACK, > obviously you don't have any list of "used VTs"... > > Then I suppose that your VT generator takes some kind of counter as > its seed, and uses and algorithm that given a 32 bit number (or less), > produces another "random" 32 bit number, which is not produced by any > other different number taken as the seed, i.e., two different seeds > produce two different VTs... So the VTs are only unique if the used > seeds are different... > > You have to keep somehow the state of which seeds have been used. And > you have to do it in a way so this state doesn't use more memory than > a fixed maximum (and small) quantity, no matter how many (and which) > seeds are in use. The only easy way I can think about now, is a simple > counter... :-/ If this is the case, won't this make easier for the > attacker to guess your "rule" of producing VTs? That rule is > reversible, so... I'm just thinking in loud voice... > > And I suppose that the way you assure that all those VTs are unique, > is the fact that 2^32 is a very big number and you won't wrap it... > Establishing an association every 10 ms will give you about one year > and a half... One association every millisecond gives you less than > two months... This numbers might be acceptable, especially taking into > account that the associations shouldn't last long, but I don't know... > :-/ > > After that time you cannot be sure that your VTs are unique... Unless, > of course, all my suppositions were wrong... :-/ > > BR Iván Arias Rodríguez It is not necessary to guarantee that the VT is unique for each association to avoid walking an address list, just that the VT and port pair are unique. I use the same MD4 swirled entropy pool that Linux TCP uses to assign secure TCP initial segment numbers with the port pair source and destination address of the INIT packet hashed into the random number. Lookups by vtag also check port pair. The probability of a duplicate on the same port pair is impossible for dynamic port allocation (as discussed in previous note) and is so slim on static port allocations that cosmic rays will mess things up first. The worst that could happen is that if two associations ever happen to be formed for the same statically allocated port pair, once in a blue moon the pair could get the same vtag for both and both associations would abort. But applications which statically assign both local and remote port are rare in themselves. There is even a way around this rarity. When the COOKIE-ECHO is received, the vtag is placed in the established hashes. If the vtag matches an existing tag in the hashes, the association can be refused and the peer forced to send another INIT which will select a different vtag. That would limit the vulnerability of a duplicate to once in a blue moon made out of green cheese with pigs flying on it and only if the implementation is ever used for multiple associations using the same static port pair assignment. Hardly worth considering. --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 Wed Feb 26 16:00: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 QAA25201 for ; Wed, 26 Feb 2003 16:00:44 -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 h1QKxS56007682 for ; Wed, 26 Feb 2003 12:59: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 h1QKxSuv022635 for ; Wed, 26 Feb 2003 12:59:28 -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 h1QKxaNY017818 for ; Wed, 26 Feb 2003 12:59:39 -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 11567244B0E; Wed, 26 Feb 2003 15:56:34 -0500 (EST) Date: Wed, 26 Feb 2003 14:58:05 -0600 From: Caitlin Bestler Subject: Re: Addr in INIT or INIT ACK To: sctp-impl@external.cisco.com Cc: bidulock@openss7.org X-Priority: 3 In-Reply-To: <20030225070518.E15879@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 2/25/03, Brian F. G. Bidulock wrote: >Where is it written that "You are not supposed to use the >VT to identify associations..." ??? As it is neither >forbidden nor counter-recommended in the RFC it is >permitted. > >And in situations like this it is particularly efficient. I have also always assumed that the VT was where you began your search for the association. That is, you looked up the VT in order to find the list of valid Sources and the list of valid Destinations for this association (and you assigned the VTAGs so that there was at most one association for each). And while I can't find where it is forbidden to use the VT for identification, I believe the intent is clearly that it is supposed to provide *additional* protection against spoofed packets. Using it *instead* of checking the source of the packet is undermining your ability to detect spoofs. I also fail to to see the benefit of not checking. If the association is single-homed on both ends, then the check is a simple comparison. If there are multiple valid remote addresses, then they have to be checked eventually anyway. Congestion control is dependent on which remote address was used. How do you do that without looking at the address? Similarly, the destination address should affect how SACKs are generated. How do you that without looking? Surely allowing a reply to be hijacked by providing an incorrect address is incorrect behavior. Caitlin Bestler http://asomi.com/CaitlinBestler/ From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Feb 26 17:47:19 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 RAA00409 for ; Wed, 26 Feb 2003 17:47: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-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1QMkW56028977 for ; Wed, 26 Feb 2003 14:46: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 ADV68305; Wed, 26 Feb 2003 14:46:31 -0800 (PST) Message-ID: <3E5D43C7.5000700@cisco.com> Date: Wed, 26 Feb 2003 16:46: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: sctp-impl@external.cisco.com Subject: New patch for BSD kame release Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all: I just wanted to announce the newest patch available for the KAME/BSD SCTP code. This patch includes all other patches of #4 plus numerous fixes and updates. You can pick up the current patch#5 from http://www.sctp.org You will need to use this with the kame snap from Monday 2/24 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-msg-core-4.cisco.com Wed Feb 26 20:15:58 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 UAA04773 for ; Wed, 26 Feb 2003 20:15:57 -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 h1R1Fo6N009866 for ; Wed, 26 Feb 2003 17:15: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 h1R1FGRj028504 for ; Wed, 26 Feb 2003 17:15:16 -0800 (PST) Received: from mail.nrd.jp (iplab08.nara.wide.ad.jp [203.178.142.17]) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id h1R1E5T6001649 for ; Wed, 26 Feb 2003 17:14:06 -0800 (PST) Received: (qmail 98746 invoked from network); 27 Feb 2003 10:11:47 +0900 Received: from unknown (HELO ?127.0.0.1?) (203.178.142.17) by iplab08.nara.wide.ad.jp with SMTP; 27 Feb 2003 10:11:47 +0900 Date: Thu, 27 Feb 2003 10:11:21 +0900 From: Katsuyoshi IIDA To: bidulock@openss7.org Subject: Re: new internet-draft has been submitted Cc: sctp-impl@external.cisco.com, Randall Stewart , lode.coene@siemens.atea.be, Peter , toshi-ku@is.aist-nara.ac.jp In-Reply-To: <20030224181231.A4465@openss7.org> References: <20030225084653.B4CC.KATSU@is.aist-nara.ac.jp> <20030224181231.A4465@openss7.org> Message-Id: <20030227095640.A569.KATSU@is.aist-nara.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Content-Transfer-Encoding: 7bit Brian, thanks for your comments. > In general the OpenSS7 implementation does not care how you set up > your IP routing tables. If SCTP can find a route to the destination > it will use it. If it cannot it cannot. If the packet is a reply > to a control chunk (other than SACK), it will attempt to use the > source address in the packet to which it is responding. If it > cannot reach that source address or the path to that source address > is suspect (has been receiving duplicates on SACKs or has excessive > retransmissions) it will use the best peer address available. Yes, I totally understand the above things you described. > In general, no multihomed configuration need have a network single > point of failure. You should investigate some of the available > implementations and see how they deal with this situation. I assure > you that it is not a problem. Hmm.. I don't think so. First, we are mainly focusing on heterogeneous wireless network, which means mobile computer has a number of wireless and different interfaces. In other words, we are trying to come up with seemless handovers in transport level using SCTP. In our scenario, mobile computer needs to maintain error counter, cwnd and some other parameters for each wireless interface. But, in some situations, the current implementations cannot provide this because the parameters are prepared for each DESTINATION address. Moreover, yes, I know, the current implementations can solve the SPOF. But I don't think it is smart enough. According to our knowledge of the current solutions, when the host detects some faults on a source interface, it is going to change the next available source interface using the round robin algorithm. From our point of view, that is very ad-hoc. There is a possibility that the source interface may be selected many times, and it may be detected failures in the past... I think this is because endpoint don't have histories of unreachability of source interface you chosen. On the other hand, we record the histories of unreachability of source inrterface we chosen. It can be helpful to select an appropriate source interface, which works correctly. I hope this helps you to understand our claims.. > If youa are looking for something to research, there are some > one-way data flow difficulties with multihoming that might interest > you. Hmm.. I don't get your point. What do you mean by "one-way data flow difficulties"? Since SCTP provides the bidirectional transport, it needs bidirectional route naturally. Or, are you trying us to go toward an enhancement of U-SCTP, which provides one-way data flow like in UDLR? If my guess is correct, they are things to be done by other guys.. Again, our main focus is seemless handover using SCTP in wireless network. We will appreciate any other comments. -- Katsuyoshi IIDA From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Wed Feb 26 20:54:53 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 UAA05731 for ; Wed, 26 Feb 2003 20:54:52 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1R1scP7008358 for ; Wed, 26 Feb 2003 17:54:38 -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 h1R1sIAa022520 for ; Wed, 26 Feb 2003 17:54:18 -0800 (PST) Received: from gw.openss7.com (IDENT:+EqIamyYApy7axkKe3A2N3JwjA5jjqv5@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1R1qkT6029812 for ; Wed, 26 Feb 2003 17:52:47 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:Eq+flZClUt/Y7Slt6JhrZGXQdYc1H4CY@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1R1mGD23268; Wed, 26 Feb 2003 18:48:16 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1R1mGC02242; Wed, 26 Feb 2003 18:48:16 -0700 Date: Wed, 26 Feb 2003 18:48:16 -0700 From: "Brian F. G. Bidulock" To: Katsuyoshi IIDA Cc: sctp-impl@external.cisco.com, Randall Stewart , lode.coene@siemens.atea.be, Peter , toshi-ku@is.aist-nara.ac.jp Subject: Re: new internet-draft has been submitted Message-ID: <20030226184816.A1810@openss7.org> Reply-To: bidulock@openss7.org References: <20030225084653.B4CC.KATSU@is.aist-nara.ac.jp> <20030224181231.A4465@openss7.org> <20030227095640.A569.KATSU@is.aist-nara.ac.jp> 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: <20030227095640.A569.KATSU@is.aist-nara.ac.jp>; from katsu@is.aist-nara.ac.jp on Thu, Feb 27, 2003 at 10:11:21AM +0900 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Katsuyoshi, On Thu, 27 Feb 2003, Katsuyoshi IIDA wrote: > Brian, thanks for your comments. > > > In general the OpenSS7 implementation does not care how you set up > > your IP routing tables. If SCTP can find a route to the destination > > it will use it. If it cannot it cannot. If the packet is a reply > > to a control chunk (other than SACK), it will attempt to use the > > source address in the packet to which it is responding. If it > > cannot reach that source address or the path to that source address > > is suspect (has been receiving duplicates on SACKs or has excessive > > retransmissions) it will use the best peer address available. > > Yes, I totally understand the above things you described. > > > In general, no multihomed configuration need have a network single > > point of failure. You should investigate some of the available > > implementations and see how they deal with this situation. I assure > > you that it is not a problem. > > Hmm.. I don't think so. First, we are mainly focusing on heterogeneous > wireless network, which means mobile computer has a number of wireless > and different interfaces. In other words, we are trying to come up > with seemless handovers in transport level using SCTP. In our > scenario, mobile computer needs to maintain error counter, cwnd and > some other parameters for each wireless interface. But, in some > situations, the current implementations cannot provide this because > the parameters are prepared for each DESTINATION address. > > Moreover, yes, I know, the current implementations can solve the SPOF. > But I don't think it is smart enough. According to our knowledge of > the current solutions, when the host detects some faults on a source > interface, it is going to change the next available source interface > using the round robin algorithm. > > ... From our point of view, that is very > ad-hoc. There is a possibility that the source interface may be > selected many times, and it may be detected failures in the past... I > think this is because endpoint don't have histories of unreachability > of source interface you chosen. > > On the other hand, we record the histories of unreachability of source > inrterface we chosen. It can be helpful to select an appropriate source > interface, which works correctly. > > I hope this helps you to understand our claims.. SCTP does not select source interface. IP does. > > > If youa are looking for something to research, there are some > > one-way data flow difficulties with multihoming that might interest > > you. > > Hmm.. I don't get your point. What do you mean by "one-way data flow > difficulties"? Since SCTP provides the bidirectional transport, it > needs bidirectional route naturally. Or, are you trying us to go > toward an enhancement of U-SCTP, which provides one-way data > flow like in UDLR? If my guess is correct, they are things to be done > by other guys.. Again, our main focus is seemless handover using SCTP > in wireless network. Data that is sent in only one direction. --brian > > We will appreciate any other comments. > -- > Katsuyoshi IIDA -- 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 Wed Feb 26 21:37: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 VAA06364 for ; Wed, 26 Feb 2003 21:37: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 h1R2at6N000501 for ; Wed, 26 Feb 2003 18:36:55 -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 h1R2asIN005438 for ; Wed, 26 Feb 2003 18:36:55 -0800 (PST) Received: from mail.nrd.jp (iplab08.nara.wide.ad.jp [203.178.142.17]) by proxy3.cisco.com (8.12.2/8.11.2) with SMTP id h1R2bANY010837 for ; Wed, 26 Feb 2003 18:37:11 -0800 (PST) Received: (qmail 700 invoked from network); 27 Feb 2003 11:35:43 +0900 Received: from unknown (HELO ?127.0.0.1?) (203.178.142.17) by iplab08.nara.wide.ad.jp with SMTP; 27 Feb 2003 11:35:43 +0900 Date: Thu, 27 Feb 2003 11:35:17 +0900 From: Katsuyoshi IIDA To: bidulock@openss7.org Subject: Re: new internet-draft has been submitted Cc: sctp-impl@external.cisco.com, Randall Stewart , lode.coene@siemens.atea.be, Peter , toshi-ku@is.aist-nara.ac.jp In-Reply-To: <20030226184816.A1810@openss7.org> References: <20030227095640.A569.KATSU@is.aist-nara.ac.jp> <20030226184816.A1810@openss7.org> Message-Id: <20030227105102.A56F.KATSU@is.aist-nara.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Content-Transfer-Encoding: 7bit Brian, > > I hope this helps you to understand our claims.. > > SCTP does not select source interface. IP does. Yes I understand, that is the current model. But, in our point of view, SCTP has some kinds of "layer violation". You know, traditional IP's responsibility is providing reachability, and traditional transport protocol's responsibility is providing transport service. SCTP violates this, because SCTP has multihoming function. In traditional layering architecture, multihoming function is provided by layer 3. What I want to say is not to criticize the layer violation of SCTP, but to make it to the best use of the layer violation. OK. I am going tell you more about this. We think our proposal provides source routing in transport layer. Our SCTP stack selects not only the destination address but also the source address, simultaneously. This is a kind of "source routing". But the every intermediate nodes between endpoints perform the traditional "hop-by-hop routing". This means we don't need to upgrade routers. We just need to upgrade endpoints. As a result, we have two routing layers: SCTP and IP. From our point of view, the current SCTP also provides a part of this routing function, but it is not enough. We just want to formalize this... Hmm... I know our proposal is a kind of radical. But I want you SCTP guys to understand our proposal, because I think our proposal is just a natural and minor enhancement of SCTP.. The original SCTP changes the destination address if a failure is detected. Our proposal also changes the source address when the destination address changes. Major thing is that SCTP introduces multihoming in transport protocol.. -- Katsuyoshi IIDA From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Feb 26 22:17:57 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 WAA06913 for ; Wed, 26 Feb 2003 22:17:56 -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 h1R3DBHK027725 for ; Wed, 26 Feb 2003 19:13:11 -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 h1R3DRWV028013 for ; Wed, 26 Feb 2003 19:13:28 -0800 (PST) Received: from gw.openss7.com (IDENT:CfIv0zrZJSFttKJip/tcfd3LXSnA2GA9@gw.openss7.com [142.179.199.224]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1R3D6AW018393 for ; Wed, 26 Feb 2003 19:13:10 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:tpengHLY3NAqtMJZSzf+vBxODno8ZfxV@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1R37SD24648; Wed, 26 Feb 2003 20:07:28 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1R37Sh03029; Wed, 26 Feb 2003 20:07:28 -0700 Date: Wed, 26 Feb 2003 20:07:28 -0700 From: "Brian F. G. Bidulock" To: Katsuyoshi IIDA Cc: sctp-impl@external.cisco.com, Randall Stewart , lode.coene@siemens.atea.be, Peter , toshi-ku@is.aist-nara.ac.jp Subject: Re: new internet-draft has been submitted Message-ID: <20030226200728.A2578@openss7.org> Reply-To: bidulock@openss7.org References: <20030227095640.A569.KATSU@is.aist-nara.ac.jp> <20030226184816.A1810@openss7.org> <20030227105102.A56F.KATSU@is.aist-nara.ac.jp> 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: <20030227105102.A56F.KATSU@is.aist-nara.ac.jp>; from katsu@is.aist-nara.ac.jp on Thu, Feb 27, 2003 at 11:35:17AM +0900 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Katsuyoshi, On Thu, 27 Feb 2003, Katsuyoshi IIDA wrote: > Brian, > > > > I hope this helps you to understand our claims.. > > > > SCTP does not select source interface. IP does. > > Yes I understand, that is the current model. But, in our point of > view, SCTP has some kinds of "layer violation". You know, traditional > IP's responsibility is providing reachability, and traditional > transport protocol's responsibility is providing transport > service. SCTP violates this, because SCTP has multihoming function. In > traditional layering architecture, multihoming function is provided by > layer 3. > > What I want to say is not to criticize the layer violation of SCTP, > but to make it to the best use of the layer violation. It is not a layer violation. SCTP need use no other services from IP than are already presented to other transport layers. IP is a datagram service. SCTP places the detination address on the datagram and IP make an effort to deliver it to its destination. This is no different than TCP or UDP's use of IP. > > OK. I am going tell you more about this. > > We think our proposal provides source routing in transport layer. Our > SCTP stack selects not only the destination address but also the > source address, simultaneously. This is a kind of "source > routing". Many IP layers will not select interface based on source address. Your proposal would require a modified IP. > > But the every intermediate nodes between endpoints perform > the traditional "hop-by-hop routing". This means we don't need to > upgrade routers. We just need to upgrade endpoints. As a result, we > have two routing layers: SCTP and IP. From our point of view, the > current SCTP also provides a part of this routing function, but it is > not enough. We just want to formalize this... No, IP provides this routing function. SCTP's selection of source address (in those IP implementations that support it) does not necessarily (and most often does not) affect IP's selection of outgoing interface. Outgoing interface selection is traditionally performed by IP (even for SCTP) and based on destination address only (sometimes TOS). > > Hmm... I know our proposal is a kind of radical. But I want you SCTP > guys to understand our proposal, because I think our proposal is just > a natural and minor enhancement of SCTP.. Your proposal would require a modification to IP to permit SCTP to select the outgoing interface. IP is not required (and should not be required) to provide this capability today. > > The original SCTP changes the destination address if a failure is > detected. Our proposal also changes the source address when the > destination address changes. You can change the source address all you like, without a modified IP layer, it will not alter the outgoing interface selection which is based solely on destination address. > > Major thing is that SCTP introduces multihoming in transport > protocol.. Yes, and for many purposes it works fine as it is. If you are having problems with outgoing interfaces on a mobile network, I suggest that you beef up your IP layer rather than trying to change SCTP. IP keeps routing metrics which affect originating interface selection. SCTP is not privy to the information or IP's criteria for outgoing interface selection. You would simply need to make your IP layer aware of the characteristics of the underlying network and give IP more intelligence in its selection of originating interface. If you are proposing moving a function (originating interface selection) currently performed by IP into SCTP, or placing it under the control of SCTP (requiring IP choose originating interface based on source address), it is unlikely to be adopted. --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 Thu Feb 27 07:15:21 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 HAA26354 for ; Thu, 27 Feb 2003 07:15: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-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1RCEu6N003008 for ; Thu, 27 Feb 2003 04:14:56 -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 h1RCEL0c010817 for ; Thu, 27 Feb 2003 04:14:22 -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 h1RCEkAW023779 for ; Thu, 27 Feb 2003 04:14:48 -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 h1RHG7p26939 for ; Thu, 27 Feb 2003 22:46:07 +0530 MIME-Version: 1.0 Message-Id: <3E5DFF19.000009.34893@vijay.india.mercurykr.com> Date: Thu, 27 Feb 2003 17:35:45 +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: Shutdown-Peer Rwnd Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA26354 Hi All, In the SCTP imp guide version 7, the following line is written ... --------- New text: (Section 9.2) --------- If there are still outstanding DATA chunks left, the SHUTDOWN receiver shall continue to follow normal data transmission procedures defined in Section 6 until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user. While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunk(s) with a SHUTDOWN chunk, and restart the T2-shutdown timer. If a SHUTDOWN chunk by itself cannot acknowledge all of the received DATA chunks (i.e. there are TSN's that can be acknowledged that are larger than the cumulative TSN and thus gaps exist in the TSN sequence) or if duplicate TSN's have been recieved then a SACK chunk MUST also be sent From statements it means that, whenever we will receive DATA chunk in SHUTDOWN-SENT state, we will reponse with the SHUTDOWN chunk and not with the SACK chunk.(except in case of gap or duplicate TSN). The SHUTDOWN chunk will contain the updated cumulative TSN. When the SHUTDOWN chunk will be received, we need to delete the data from the queue upto the cumulative TSN and update Flight size and Peer Rwnd. Since in the SHUTDOWN chunk Peer Rwnd field is not there .... We may end up with the wrong value of Peer Rwnd. How to calculate the Peer Rwnd in this case ?? Regards, Vijay From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Feb 27 09:40:21 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 JAA05644 for ; Thu, 27 Feb 2003 09:40:20 -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 h1REWwP7019791; Thu, 27 Feb 2003 06:32:58 -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 ADW36701; Thu, 27 Feb 2003 06:33:06 -0800 (PST) Message-ID: <3E5E21A2.7040704@cisco.com> Date: Thu, 27 Feb 2003 08:33:06 -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: Shutdown-Peer Rwnd References: <3E5DFF19.000009.34893@vijay.india.mercurykr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Kumar Choudhary wrote: >Hi All, > In the SCTP imp guide version 7, the following line is written ... > >--------- > New text: (Section 9.2) > --------- > If there are still outstanding DATA chunks left, the SHUTDOWN > receiver shall continue to follow normal data transmission procedures > defined in Section 6 until all outstanding DATA chunks are acknowledged; >however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP >user. > > While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately >respond to each received packet containing one or more DATA chunk(s) with >a SHUTDOWN chunk, and restart the T2-shutdown timer. If a > SHUTDOWN chunk by itself cannot acknowledge all of the received DATA > chunks (i.e. there are TSN's that can be acknowledged that are larger > than the cumulative TSN and thus gaps exist in the TSN sequence) or > if duplicate TSN's have been recieved then a SACK chunk MUST also be sent > > > > > >>From statements it means that, whenever we will receive DATA chunk in >SHUTDOWN-SENT state, we will reponse with the SHUTDOWN chunk and not with >the SACK chunk.(except in case of gap or duplicate TSN). The SHUTDOWN chunk >will contain the updated cumulative TSN. When the SHUTDOWN chunk will be >received, we need to delete the data from the queue upto the cumulative TSN >and update Flight size and Peer Rwnd. >Since in the SHUTDOWN chunk Peer Rwnd field is not there .... We may end up >with the wrong value of Peer Rwnd. > How to calculate the Peer Rwnd in this case ?? > >Regards, >Vijay > > > Vijay: You MUST respond with a SHUTDOWN.. but I also always bundle a SACK with the SHUTDOWN... this way it is not a problem... Another thing to remember is that you are at the end of the association at this point... I don't think large volumes of data transfer would be a concern.. 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 Thu Feb 27 19:14: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 TAA28552 for ; Thu, 27 Feb 2003 19:14:55 -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 h1S09dP7023214 for ; Thu, 27 Feb 2003 16:09:39 -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 h1S09p6s011938 for ; Thu, 27 Feb 2003 16:09:51 -0800 (PST) Received: from thebe.your-site.com (ns5.your-site.com [140.186.45.30] (may be forged)) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id h1S09SIS008037 for ; Thu, 27 Feb 2003 16:09:33 -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 18B4E244C43 for ; Thu, 27 Feb 2003 19:06:49 -0500 (EST) Date: Thu, 27 Feb 2003 18:08:23 -0600 From: Caitlin Bestler Subject: Re: new internet-draft has been submitted 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 On 2/27/03, Katsuyoshi IIDA wrote: >Hmm.. I don't think so. First, we are mainly focusing on >heterogeneous wireless network, which means mobile >computer has a number of wireless and different >interfaces. In other words, we are trying to come up with >seemless handovers in transport level using SCTP. In our >scenario, mobile computer needs to maintain error counter, >cwnd and some other parameters for each wireless >interface. But, in some situations, the current >implementations cannot provide this because the parameters >are prepared for each DESTINATION address. > >Moreover, yes, I know, the current implementations can >solve the SPOF. But I don't think it is smart enough. >According to our knowledge of the current solutions, when >the host detects some faults on a source interface, it is >going to change the next available source interface using >the round robin algorithm. From our point of view, that is >very ad-hoc. There is a possibility that the source >interface may be selected many times, and it may be >detected failures in the past... I think this is because >endpoint don't have histories of unreachability of source >interface you chosen. The issue you are focusing on is worthy of attention, but I think you are approaching it incorrectly. The problem worthy of attention deals with how to optimize source interface / address selection under special networking situations. Specifically, in a wireless network transient errors related to a specific *local* path are predictable (indeed that is why there are multiple paths). But that is one corner of the network. The nature of the cloud is unchanged, and the nature of the destination network is unchanged. I suggest you review prior discussions on why congestion is calculated based upon the destination address rather than on a presumed "path". The issues are unchanged. In particular knowing a "path" through the "cloud" is hopeless. The cloud is unknown and subject to change without notice. That is why PMTU discovery is a *process*, not an attribute of the path object. I believe an SCTP implementation can optimize for its end being wireless interfaces and still be RFC2960 compliant. Wireless networks are generally shared media that lack any carrier sense capability. Basically, any given transmitter has no way to know that it is colliding with another concurrent transmitter. Most solve this by time-slicing. A certain number of slots are available via blind contention. These are used to request permission to send an upstream message. The others are assigned by a L1/L2 network controller. The key is that the L1/L2 communications required to grant permission to transmit will fully diagnose transmit problems. If L2 permission to transmit can be achieved, the IP datagram sent will generally be as reliable as with a wired network (Especially when combined with Forward Error Correction). Additionally, wireless networks frequently employ forward error correction downstream as well. This, and other signal data, can provide a receiver with an early warning that a given downstream path is becoming unreliable. Signal/Noise ratios fall, the number of error corrections required rises. In terms of transmission, this additional information can be used when selecting a source address/interface. The question is then whether it makes sense for a wireless receiver to detect that one of its addresses is "going down", and to notify its peer to switch the primary address that is being used to reach it. I haven't done an exhaustive analysis on this topic, but my hunch is that this in not worthwhile. It is true that "early warning" is a capability not usually found in wire networks, and therefore ignored. But the time lags of correcting the problem at the other end of the association strike me as self-defeating. Correcting it at the local end where "the Internet" is connected to the wireless network would make more sense to me. An ARP-like function can be used to simply route downstream IP datagrams to a new frequency or transmitter. Do you have an analysis of problem unique to wireless networks that shows why it should be solved at the IP level on an end-to-end basis? My initial reaction is that the SCTP stack and the wired-to-wireless Router can solve these problems using L1/L2 information. Caitlin Bestler http://asomi.com/CaitlinBestler/ From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Feb 27 20:33:23 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 UAA29751 for ; Thu, 27 Feb 2003 20:33:22 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1S1T5P7020541 for ; Thu, 27 Feb 2003 17:29:05 -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 h1S1Sixa003922 for ; Thu, 27 Feb 2003 17:28:44 -0800 (PST) Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id h1S1RIT6014930 for ; Thu, 27 Feb 2003 17:27:19 -0800 (PST) Received: from LocalHost (sjkoh.etri.re.kr [129.254.112.15]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F3RQBSBN; Fri, 28 Feb 2003 10:24:45 +0900 Message-ID: <001101c2dec8$1ecfde40$0f70fe81@LocalHost> From: "Seok Joo Koh" To: References: Subject: trigtran BOF and SCTP Date: Fri, 28 Feb 2003 10:24:21 +0900 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 Content-Transfer-Encoding: 7bit In this IETF meeting, Trigtran BOF will be open. http://www.ietf.org/ietf/03mar/trigtran.txt In my guess, its scope or issue seems to be also related to the SCTP multi-homing behaviors. Who can let me know some relationship or interactions between trigtran and SCTP ? Best Regards Seok Joo Koh sjkoh@etri.re.kr http://ectp.etri.re.kr/~sjkoh From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Feb 27 20:33:33 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 UAA29777 for ; Thu, 27 Feb 2003 20:33:32 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1S1WhP7024368 for ; Thu, 27 Feb 2003 17:32: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 h1S1WL7V006187 for ; Thu, 27 Feb 2003 17:32:21 -0800 (PST) Received: from mail.nrd.jp (iplab08.nara.wide.ad.jp [203.178.142.17]) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id h1S1V7T6018326 for ; Thu, 27 Feb 2003 17:31:08 -0800 (PST) Received: (qmail 29472 invoked from network); 28 Feb 2003 10:28:11 +0900 Received: from unknown (HELO ?127.0.0.1?) (203.178.142.17) by iplab08.nara.wide.ad.jp with SMTP; 28 Feb 2003 10:28:11 +0900 Date: Fri, 28 Feb 2003 10:27:47 +0900 From: Katsuyoshi IIDA To: Caitlin Bestler Subject: Re: new internet-draft has been submitted Cc: sctp-impl@external.cisco.com In-Reply-To: References: Message-Id: <20030228092951.AA94.KATSU@is.aist-nara.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Content-Transfer-Encoding: 7bit Caitlin, thank you for your insightful comments. On Thu, 27 Feb 2003 18:08:23 -0600 Caitlin Bestler wrote: > On 2/27/03, Katsuyoshi IIDA wrote: > > >Hmm.. I don't think so. First, we are mainly focusing on > >heterogeneous wireless network, which means mobile > >computer has a number of wireless and different > >interfaces. In other words, we are trying to come up with > >seemless handovers in transport level using SCTP. In our > >scenario, mobile computer needs to maintain error counter, > >cwnd and some other parameters for each wireless > >interface. But, in some situations, the current > >implementations cannot provide this because the parameters > >are prepared for each DESTINATION address. > > > >Moreover, yes, I know, the current implementations can > >solve the SPOF. But I don't think it is smart enough. > >According to our knowledge of the current solutions, when > >the host detects some faults on a source interface, it is > >going to change the next available source interface using > >the round robin algorithm. From our point of view, that is > >very ad-hoc. There is a possibility that the source > >interface may be selected many times, and it may be > >detected failures in the past... I think this is because > >endpoint don't have histories of unreachability of source > >interface you chosen. > > The issue you are focusing on is worthy of attention, but I > think you are approaching it incorrectly. > > The problem worthy of attention deals with how to optimize > source interface / address selection under special > networking situations. Specifically, in a wireless network > transient errors related to a specific *local* path are > predictable (indeed that is why there are multiple paths). > > But that is one corner of the network. The nature of the > cloud is unchanged, and the nature of the destination > network is unchanged. > > I suggest you review prior discussions on why congestion is > calculated based upon the destination address rather than on > a presumed "path". The issues are unchanged. Thank you for your good suggestions. I will try to read the discussions. (Actually, we had finished to read the SCTP book written by Randall R. Stewart and Qiaobing Xie in half year ago. I don't remember the details, so I will read again when I return my home country. I am now in business trip..) > In particular knowing a "path" through the "cloud" is > hopeless. The cloud is unknown and subject to change without > notice. That is why PMTU discovery is a *process*, not an > attribute of the path object. Yes, I understand you want to say. But, our assumption is that the most nearest link to the endpoints are the most critical links. How do we recover the packet fault on such link? is our question. Again, I will try to read the prior discussions to get full understanding. > I believe an SCTP implementation can optimize for its end > being wireless interfaces and still be RFC2960 compliant. > > Wireless networks are generally shared media that lack any > carrier sense capability. Basically, any given transmitter > has no way to know that it is colliding with another > concurrent transmitter. > > Most solve this by time-slicing. A certain number of slots > are available via blind contention. These are used to > request permission to send an upstream message. The others > are assigned by a L1/L2 network controller. > > The key is that the L1/L2 communications required to grant > permission to transmit will fully diagnose transmit > problems. If L2 permission to transmit can be achieved, > the IP datagram sent will generally be as reliable as with > a wired network (Especially when combined with Forward Error > Correction). > > Additionally, wireless networks frequently employ forward > error correction downstream as well. This, and other signal > data, can provide a receiver with an early warning that a > given downstream path is becoming unreliable. Signal/Noise > ratios fall, the number of error corrections required rises. > > In terms of transmission, this additional information can be > used when selecting a source address/interface. > > The question is then whether it makes sense for a wireless > receiver to detect that one of its addresses is "going > down", and to notify its peer to switch the primary address > that is being used to reach it. > > I haven't done an exhaustive analysis on this topic, but my > hunch is that this in not worthwhile. It is true that "early > warning" is a capability not usually found in wire networks, > and therefore ignored. But the time lags of correcting the > problem at the other end of the association strike me as > self-defeating. Correcting it at the local end where "the > Internet" is connected to the wireless network would make > more sense to me. An ARP-like function can be used to simply > route downstream IP datagrams to a new frequency or > transmitter. > > Do you have an analysis of problem unique to wireless > networks that shows why it should be solved at the IP level > on an end-to-end basis? My initial reaction is that the SCTP > stack and the wired-to-wireless Router can solve these > problems using L1/L2 information. No, we don't have it yet. Actually, this work is a part of two master's thesis under my supervision. In the defense presentation, some thesis advisors asked the same question. Why don't you use the L1 and L2 information. Yes, we would like to do that. But, the current work is just a first step. We will enhance our work. By the way, we have some primary simulation results, where the link characteristic (including packet loss, delay, and bandwidth) is changing in time. But the characteristic changing are not followed by wireless characteristic but just artificial setting. Moreover, the document is written in Japanese. Since we are now preparing to submit an international conference quite soon, I will give you the document when we finish it. Thanks again for your insightful comments. Since we would like to contribute something in this community, we will refer to your advises. -- Katsuyoshi IIDA