From exim@www1.ietf.org Mon Jan 5 17:42:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08995 for ; Mon, 5 Jan 2004 17:42:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AddQE-0000df-3q for tsvwg-archive@odin.ietf.org; Mon, 05 Jan 2004 17:42:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05Mg640002451 for tsvwg-archive@odin.ietf.org; Mon, 5 Jan 2004 17:42:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AddQ9-0000dD-C7; Mon, 05 Jan 2004 17:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AatEX-0002J4-Bi for tsvwg@optimus.ietf.org; Mon, 29 Dec 2003 03:58:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20289 for ; Mon, 29 Dec 2003 03:58:39 -0500 (EST) From: Mikael.Latvala@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AatEP-0005kk-00 for tsvwg@ietf.org; Mon, 29 Dec 2003 03:58:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AatAN-0005hh-00 for tsvwg@ietf.org; Mon, 29 Dec 2003 03:54:24 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aat71-0005ds-00 for tsvwg@ietf.org; Mon, 29 Dec 2003 03:50:55 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBT8oaU28703 for ; Mon, 29 Dec 2003 10:50:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 29 Dec 2003 10:50:35 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 29 Dec 2003 10:50:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] Establishment of SCTP association Date: Mon, 29 Dec 2003 10:50:31 +0200 Message-ID: <9B2635C00D654F4CA36B89C22364F0C30154B991@esebe008.ntc.nokia.com> Thread-Topic: [Tsvwg] Establishment of SCTP association Thread-Index: AcPG8We3DH3pznTFTq+DYcdmqrgM4gG8HPWw To: Cc: X-OriginalArrivalTime: 29 Dec 2003 08:50:35.0417 (UTC) FILETIME=[D317E090:01C3CDE8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Michael, I agree, that true man-in-middle can do lots of harm at the transport = layer. However, association highjack is definately the worst one. If you want to use IPsec against such attacks, configuring IPsec becomes = in no time mission impossible, if INIT-ACK's source IP address can be = different than INIT's destination IP address. Simple because if this is = allowed, person configuring IPsec policy database must know before hand = any IP address that the peer may use in an SCTP assocation. However, if INIT-ACK's source IP address would be always the same than = INIT's destination IP address, then person in charge of configuring = IPsec policy database would have to know only one IP address. The other = additional IP addresses negotiated during and possibly after SCTP = association setup could be dynamically added to the IPsec policy = database. Obviously one could use wildcard in a source selector field in IPsec = policy database. Unfortunately there are plenty of companies who do not = approve such security policy.=20 Therefore I am requesting that SCTP implementor's guide and/or SCTP = dynamic address recofiguration documents discuss about this problem and = explicitly forbid any SCTP implementation from using IP address in = INIT-ACK that is different from INIT's destination IP address. /Mikael > -----Original Message----- > From: ext Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] > Sent: Saturday, December 20, 2003 2:03 PM > To: Latvala Mikael (NET/Helsinki) > Cc: tsvwg@ietf.org > Subject: Re: [Tsvwg] Establishment of SCTP association >=20 >=20 > Mikael, >=20 > a true man-in-middle can do everything: insert ABORTs when he=20 > wants and=20 > so on. > And not allowing that the other IP address is used as a=20 > source address=20 > does not > hel you. The true man in the middle can intercept the packet=20 > and return=20 > the > INIT-ACK with B's address as a source address. In general: a true=20 > man-in-the-middle > can do everything and there is not much a transport layer can do. You=20 > must > have some mechanism to identify your peer not based on the IP=20 > address.=20 > Possibilities > include IPSec or TLS. >=20 > Best regards > Michael >=20 >=20 > On 17. Dec 2003, at 16:33 Uhr, Mikael.Latvala@nokia.com wrote: >=20 > > Hello, > > > > We noticed an interesting behaviour in Linux SCTP implementation. > > > > 1. Endpoint A sends an INIT chunk to endpoint B using IPa=20 > as a source=20 > > IP address and IPb as a destination IP address > > > > 2. Endpoint B returns INIT ACK to endpoint A using IPc as a=20 > source IP=20 > > address and IPa as a destination IP address. IPb is=20 > included in INIT=20 > > ACK as an address parameter. > > > > 3. A and B finish the association negotiation, endpoint A=20 > using IPb as=20 > > its primary IP address and endpoint B using IPc as a source address=20 > > when it sends data chunks to endpoint A. > > > > My question is: although RFRC2960 does not explicitly deny=20 > the use of=20 > > IPc as a source IP address in INIT ACK, when implementation=20 > does so,=20 > > doesn't this present a security hole in the association setup=20 > > procedure? Therefore such behaviour should not be allowed. > > > > For example, in a man-in-the-middle attack hostile node=20 > could highjack=20 > > the association by responding to INIT, which endpoint A=20 > sent, faster=20 > > than endpoint B, using hostile node's own IP address IPz as=20 > a source=20 > > IP address. Obviously this attack assumes that the endpoint=20 > A selects=20 > > the source IP address IPz as its primary IP address. > > > > /Mikael > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > > >=20 >=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jan 5 18:31:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11756 for ; Mon, 5 Jan 2004 18:31:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeBc-0002oG-Cg for tsvwg-archive@odin.ietf.org; Mon, 05 Jan 2004 18:31:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05NV4ts010777 for tsvwg-archive@odin.ietf.org; Mon, 5 Jan 2004 18:31:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeBZ-0002mQ-5Z; Mon, 05 Jan 2004 18:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeAb-0002Vf-32 for tsvwg@optimus.ietf.org; Mon, 05 Jan 2004 18:30:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11561 for ; Mon, 5 Jan 2004 18:29:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdeAX-00004D-00 for tsvwg@ietf.org; Mon, 05 Jan 2004 18:29:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdduV-0006Sc-00 for tsvwg@ietf.org; Mon, 05 Jan 2004 18:13:24 -0500 Received: from gw.openss7.com ([142.179.199.224] ident=[aiIT3YZk8mfB4rP+HGZ8EYEBCPJXrwBo]) by ietf-mx with esmtp (Exim 4.12) id 1AddpJ-0005bb-00 for tsvwg@ietf.org; Mon, 05 Jan 2004 18:08:02 -0500 Received: from ns.pigworks.openss7.net (IDENT:AlDda1d1ewfk3b96wIWXG7fCJIp27+RN@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i05N7aI11589; Mon, 5 Jan 2004 16:07:36 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i05N7a930338; Mon, 5 Jan 2004 16:07:36 -0700 Date: Mon, 5 Jan 2004 16:07:36 -0700 From: "Brian F. G. Bidulock" To: Mikael.Latvala@nokia.com Cc: Michael.Tuexen@lurchi.franken.de, tsvwg@ietf.org Subject: Re: [Tsvwg] Establishment of SCTP association Message-ID: <20040105160736.B29922@openss7.org> Reply-To: bidulock@openss7.org References: <9B2635C00D654F4CA36B89C22364F0C30154B991@esebe008.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <9B2635C00D654F4CA36B89C22364F0C30154B991@esebe008.ntc.nokia.com>; from Mikael.Latvala@nokia.com on Mon, Dec 29, 2003 at 10:50:31AM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id i05N7aI11589 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Mikael.Latvala, Doing so would destroy the reliability of a multi-homed association. As = an operator's policy, the operator is welcome to prohibit multi-homed associations altogether. Then the operator can be sure that the INIT-ACK address is the same as the INIT. I think you speak of a operational issu= e rather than a protocol issue. --brian On Mon, 29 Dec 2003, Mikael.Latvala@nokia.com wrote: > Michael, >=20 > I agree, that true man-in-middle can do lots of harm at the transport l= ayer. However, association highjack is definately the worst one. >=20 > If you want to use IPsec against such attacks, configuring IPsec become= s in no time mission impossible, if INIT-ACK's source IP address can be d= ifferent than INIT's destination IP address. Simple because if this is al= lowed, person configuring IPsec policy database must know before hand any= IP address that the peer may use in an SCTP assocation. >=20 > However, if INIT-ACK's source IP address would be always the same than = INIT's destination IP address, then person in charge of configuring IPsec= policy database would have to know only one IP address. The other addit= ional IP addresses negotiated during and possibly after SCTP association = setup could be dynamically added to the IPsec policy database. >=20 > Obviously one could use wildcard in a source selector field in IPsec po= licy database. Unfortunately there are plenty of companies who do not app= rove such security policy.=20 >=20 > Therefore I am requesting that SCTP implementor's guide and/or SCTP dyn= amic address recofiguration documents discuss about this problem and expl= icitly forbid any SCTP implementation from using IP address in INIT-ACK t= hat is different from INIT's destination IP address. >=20 > /Mikael >=20 > > -----Original Message----- > > From: ext Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] > > Sent: Saturday, December 20, 2003 2:03 PM > > To: Latvala Mikael (NET/Helsinki) > > Cc: tsvwg@ietf.org > > Subject: Re: [Tsvwg] Establishment of SCTP association > >=20 > >=20 > > Mikael, > >=20 > > a true man-in-middle can do everything: insert ABORTs when he=20 > > wants and=20 > > so on. > > And not allowing that the other IP address is used as a=20 > > source address=20 > > does not > > hel you. The true man in the middle can intercept the packet=20 > > and return=20 > > the > > INIT-ACK with B's address as a source address. In general: a true=20 > > man-in-the-middle > > can do everything and there is not much a transport layer can do. You= =20 > > must > > have some mechanism to identify your peer not based on the IP=20 > > address.=20 > > Possibilities > > include IPSec or TLS. > >=20 > > Best regards > > Michael > >=20 > >=20 > > On 17. Dec 2003, at 16:33 Uhr, Mikael.Latvala@nokia.com wrote: > >=20 > > > Hello, > > > > > > We noticed an interesting behaviour in Linux SCTP implementation. > > > > > > 1. Endpoint A sends an INIT chunk to endpoint B using IPa=20 > > as a source=20 > > > IP address and IPb as a destination IP address > > > > > > 2. Endpoint B returns INIT ACK to endpoint A using IPc as a=20 > > source IP=20 > > > address and IPa as a destination IP address. IPb is=20 > > included in INIT=20 > > > ACK as an address parameter. > > > > > > 3. A and B finish the association negotiation, endpoint A=20 > > using IPb as=20 > > > its primary IP address and endpoint B using IPc as a source address= =20 > > > when it sends data chunks to endpoint A. > > > > > > My question is: although RFRC2960 does not explicitly deny=20 > > the use of=20 > > > IPc as a source IP address in INIT ACK, when implementation=20 > > does so,=20 > > > doesn't this present a security hole in the association setup=20 > > > procedure? Therefore such behaviour should not be allowed. > > > > > > For example, in a man-in-the-middle attack hostile node=20 > > could highjack=20 > > > the association by responding to INIT, which endpoint A=20 > > sent, faster=20 > > > than endpoint B, using hostile node's own IP address IPz as=20 > > a source=20 > > > IP address. Obviously this attack assumes that the endpoint=20 > > A selects=20 > > > the source IP address IPz as its primary IP address. > > > > > > /Mikael > > > > > > _______________________________________________ > > > tsvwg mailing list > > > tsvwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/tsvwg > > > > >=20 > >=20 >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jan 5 19:24:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15289 for ; Mon, 5 Jan 2004 19:24:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adf0s-0005ib-U7 for tsvwg-archive@odin.ietf.org; Mon, 05 Jan 2004 19:24:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i060O2fs021975 for tsvwg-archive@odin.ietf.org; Mon, 5 Jan 2004 19:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adf0r-0005iG-2v; Mon, 05 Jan 2004 19:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adf0A-0005hj-6e for tsvwg@optimus.ietf.org; Mon, 05 Jan 2004 19:23:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15282 for ; Mon, 5 Jan 2004 19:23:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adf03-00056H-00 for tsvwg@ietf.org; Mon, 05 Jan 2004 19:23:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adeve-0004z1-00 for tsvwg@ietf.org; Mon, 05 Jan 2004 19:18:39 -0500 Received: from mail-n.franken.de ([193.175.24.27] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AdesS-0004rC-00 for tsvwg@ietf.org; Mon, 05 Jan 2004 19:15:20 -0500 Received: from [10.0.1.2] (p5089EC9F.dip.t-dialin.net [80.137.236.159]) by mail-n.franken.de (Postfix) with ESMTP id 926DC2460F; Tue, 6 Jan 2004 01:14:38 +0100 (CET) In-Reply-To: <9B2635C00D654F4CA36B89C22364F0C30154B991@esebe008.ntc.nokia.com> References: <9B2635C00D654F4CA36B89C22364F0C30154B991@esebe008.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1CA5228A-3FDD-11D8-914F-000A95C37894@lurchi.franken.de> Content-Transfer-Encoding: 7bit Cc: From: Michael Tuexen Subject: Re: [Tsvwg] Establishment of SCTP association Date: Tue, 6 Jan 2004 01:13:10 +0100 To: Mikael.Latvala@nokia.com X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mikael, see my comments below. Best regards Michael On 29. Dec 2003, at 9:50 Uhr, Mikael.Latvala@nokia.com wrote: > Michael, > > I agree, that true man-in-middle can do lots of harm at the transport > layer. However, association highjack is definately the worst one. > > If you want to use IPsec against such attacks, configuring IPsec > becomes in no time mission impossible, if INIT-ACK's source IP address > can be different than INIT's destination IP address. Simple because if > this is allowed, person configuring IPsec policy database must know > before hand any IP address that the peer may use in an SCTP > assocation. > > However, if INIT-ACK's source IP address would be always the same than > INIT's destination IP address, then person in charge of configuring > IPsec policy database would have to know only one IP address. The > other additional IP addresses negotiated during and possibly after > SCTP association setup could be dynamically added to the IPsec policy > database. > I agree with you that if one peer has n addresses and the other m the person has to set up 2 * n * m SAs and he must know all addresses before the association is set up. The problem in requiring the source address of the INIT-ACk is the same as the destination address of the INIT is not so simple to fulfill. If the SCTP stack does not control the source address by itself but relies on the kernel to do that based on the routing table then you can not guarantee that. If have seen several implementations working like this. > Obviously one could use wildcard in a source selector field in IPsec > policy database. Unfortunately there are plenty of companies who do > not approve such security policy. > > Therefore I am requesting that SCTP implementor's guide and/or SCTP > dynamic address recofiguration documents discuss about this problem > and explicitly forbid any SCTP implementation from using IP address in > INIT-ACK that is different from INIT's destination IP address. > Are you talking about plain SCTP (RFC 2960) or the ADDIP ID. The AddIP ID will be updated with additional security mechanisms. > /Mikael > >> -----Original Message----- >> From: ext Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >> Sent: Saturday, December 20, 2003 2:03 PM >> To: Latvala Mikael (NET/Helsinki) >> Cc: tsvwg@ietf.org >> Subject: Re: [Tsvwg] Establishment of SCTP association >> >> >> Mikael, >> >> a true man-in-middle can do everything: insert ABORTs when he >> wants and >> so on. >> And not allowing that the other IP address is used as a >> source address >> does not >> hel you. The true man in the middle can intercept the packet >> and return >> the >> INIT-ACK with B's address as a source address. In general: a true >> man-in-the-middle >> can do everything and there is not much a transport layer can do. You >> must >> have some mechanism to identify your peer not based on the IP >> address. >> Possibilities >> include IPSec or TLS. >> >> Best regards >> Michael >> >> >> On 17. Dec 2003, at 16:33 Uhr, Mikael.Latvala@nokia.com wrote: >> >>> Hello, >>> >>> We noticed an interesting behaviour in Linux SCTP implementation. >>> >>> 1. Endpoint A sends an INIT chunk to endpoint B using IPa >> as a source >>> IP address and IPb as a destination IP address >>> >>> 2. Endpoint B returns INIT ACK to endpoint A using IPc as a >> source IP >>> address and IPa as a destination IP address. IPb is >> included in INIT >>> ACK as an address parameter. >>> >>> 3. A and B finish the association negotiation, endpoint A >> using IPb as >>> its primary IP address and endpoint B using IPc as a source address >>> when it sends data chunks to endpoint A. >>> >>> My question is: although RFRC2960 does not explicitly deny >> the use of >>> IPc as a source IP address in INIT ACK, when implementation >> does so, >>> doesn't this present a security hole in the association setup >>> procedure? Therefore such behaviour should not be allowed. >>> >>> For example, in a man-in-the-middle attack hostile node >> could highjack >>> the association by responding to INIT, which endpoint A >> sent, faster >>> than endpoint B, using hostile node's own IP address IPz as >> a source >>> IP address. Obviously this attack assumes that the endpoint >> A selects >>> the source IP address IPz as its primary IP address. >>> >>> /Mikael >>> >>> _______________________________________________ >>> tsvwg mailing list >>> tsvwg@ietf.org >>> https://www1.ietf.org/mailman/listinfo/tsvwg >>> >> >> > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jan 6 09:52:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19938 for ; Tue, 6 Jan 2004 09:52:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsYw-00044I-VR for tsvwg-archive@odin.ietf.org; Tue, 06 Jan 2004 09:52:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06Eq6pB015634 for tsvwg-archive@odin.ietf.org; Tue, 6 Jan 2004 09:52:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsYq-000441-Fw; Tue, 06 Jan 2004 09:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsYd-00042x-OB for tsvwg@optimus.ietf.org; Tue, 06 Jan 2004 09:51:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19919 for ; Tue, 6 Jan 2004 09:51:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdsYb-0000EA-00 for tsvwg@ietf.org; Tue, 06 Jan 2004 09:51:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdsWq-00009z-00 for tsvwg@ietf.org; Tue, 06 Jan 2004 09:49:57 -0500 Received: from [67.38.193.238] (helo=stewart.chicago.il.us) by ietf-mx with esmtp (Exim 4.12) id 1AdsVl-00005J-00 for tsvwg@ietf.org; Tue, 06 Jan 2004 09:48:49 -0500 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id i06EmhO6083908; Tue, 6 Jan 2004 08:48:45 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3FFACA9D.3080904@stewart.chicago.il.us> Date: Tue, 06 Jan 2004 08:47:57 -0600 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen , Mikael.Latvala@nokia.com CC: tsvwg@ietf.org Subject: Re: [Tsvwg] Establishment of SCTP association References: <9B2635C00D654F4CA36B89C22364F0C30154B991@esebe008.ntc.nokia.com> <1CA5228A-3FDD-11D8-914F-000A95C37894@lurchi.franken.de> In-Reply-To: <1CA5228A-3FDD-11D8-914F-000A95C37894@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mikael/Michael: My comments below.. Michael Tuexen wrote: > Mikael, > > see my comments below. > > Best regards > Michael > > On 29. Dec 2003, at 9:50 Uhr, Mikael.Latvala@nokia.com wrote: > >> Michael, >> >> I agree, that true man-in-middle can do lots of harm at the transport >> layer. However, association highjack is definately the worst one. >> >> If you want to use IPsec against such attacks, configuring IPsec >> becomes in no time mission impossible, if INIT-ACK's source IP >> address can be different than INIT's destination IP address. Simple >> because if this is allowed, person configuring IPsec policy database >> must know before hand any IP address that the peer may use in an SCTP >> assocation. >> >> However, if INIT-ACK's source IP address would be always the same >> than INIT's destination IP address, then person in charge of >> configuring IPsec policy database would have to know only one IP >> address. The other additional IP addresses negotiated during and >> possibly after SCTP association setup could be dynamically added to >> the IPsec policy database. >> > I agree with you that if one peer has n addresses and the other m the > person has to set up 2 * n * m SAs and he must know > all addresses before the association is set up. > The problem in requiring the source address of the INIT-ACk is the > same as the destination address of the INIT is not > so simple to fulfill. If the SCTP stack does not control the source > address by itself but relies on the kernel to do > that based on the routing table then you can not guarantee that. If > have seen several implementations working like this. Besides this, the whole point of the IPSEC-SCTP RFC (don't know if it is out yet) is to setup the SP's on each side of an IPSEC exchange of all the addresses. This is a pre-requesite.. if you want to do multi-homed SCTP over an IPSEC exchange then you must build into the spid all of the address on each side... I don't think any of the IPSEC implementations have yet caught up to this.. but it is needed... it is not a problem with SCTP but a fundamental problem that needs to be fixed in IPSEC. R > >> Obviously one could use wildcard in a source selector field in IPsec >> policy database. Unfortunately there are plenty of companies who do >> not approve such security policy. >> >> Therefore I am requesting that SCTP implementor's guide and/or SCTP >> dynamic address recofiguration documents discuss about this problem >> and explicitly forbid any SCTP implementation from using IP address >> in INIT-ACK that is different from INIT's destination IP address. >> > Are you talking about plain SCTP (RFC 2960) or the ADDIP ID. The AddIP > ID will be updated with additional security > mechanisms. > >> /Mikael >> >>> -----Original Message----- >>> From: ext Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >>> Sent: Saturday, December 20, 2003 2:03 PM >>> To: Latvala Mikael (NET/Helsinki) >>> Cc: tsvwg@ietf.org >>> Subject: Re: [Tsvwg] Establishment of SCTP association >>> >>> >>> Mikael, >>> >>> a true man-in-middle can do everything: insert ABORTs when he >>> wants and >>> so on. >>> And not allowing that the other IP address is used as a >>> source address >>> does not >>> hel you. The true man in the middle can intercept the packet >>> and return >>> the >>> INIT-ACK with B's address as a source address. In general: a true >>> man-in-the-middle >>> can do everything and there is not much a transport layer can do. You >>> must >>> have some mechanism to identify your peer not based on the IP >>> address. >>> Possibilities >>> include IPSec or TLS. >>> >>> Best regards >>> Michael >>> >>> >>> On 17. Dec 2003, at 16:33 Uhr, Mikael.Latvala@nokia.com wrote: >>> >>>> Hello, >>>> >>>> We noticed an interesting behaviour in Linux SCTP implementation. >>>> >>>> 1. Endpoint A sends an INIT chunk to endpoint B using IPa >>> >>> as a source >>> >>>> IP address and IPb as a destination IP address >>>> >>>> 2. Endpoint B returns INIT ACK to endpoint A using IPc as a >>> >>> source IP >>> >>>> address and IPa as a destination IP address. IPb is >>> >>> included in INIT >>> >>>> ACK as an address parameter. >>>> >>>> 3. A and B finish the association negotiation, endpoint A >>> >>> using IPb as >>> >>>> its primary IP address and endpoint B using IPc as a source address >>>> when it sends data chunks to endpoint A. >>>> >>>> My question is: although RFRC2960 does not explicitly deny >>> >>> the use of >>> >>>> IPc as a source IP address in INIT ACK, when implementation >>> >>> does so, >>> >>>> doesn't this present a security hole in the association setup >>>> procedure? Therefore such behaviour should not be allowed. >>>> >>>> For example, in a man-in-the-middle attack hostile node >>> >>> could highjack >>> >>>> the association by responding to INIT, which endpoint A >>> >>> sent, faster >>> >>>> than endpoint B, using hostile node's own IP address IPz as >>> >>> a source >>> >>>> IP address. Obviously this attack assumes that the endpoint >>> >>> A selects >>> >>>> the source IP address IPz as its primary IP address. >>>> >>>> /Mikael >>>> >>>> _______________________________________________ >>>> tsvwg mailing list >>>> tsvwg@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/tsvwg >>>> >>> >>> >> >> _______________________________________________ >> tsvwg mailing list >> tsvwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/tsvwg >> > > > _______________________________________________ > 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) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jan 7 09:19:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10817 for ; Wed, 7 Jan 2004 09:19:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEWY-0005Zq-1E for tsvwg-archive@odin.ietf.org; Wed, 07 Jan 2004 09:19:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07EJ5hc021434 for tsvwg-archive@odin.ietf.org; Wed, 7 Jan 2004 09:19:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEWT-0005ZS-9n; Wed, 07 Jan 2004 09:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEVX-0005TL-H7 for tsvwg@optimus.ietf.org; Wed, 07 Jan 2004 09:18:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10757 for ; Wed, 7 Jan 2004 09:18:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeEVV-0004m0-00 for tsvwg@ietf.org; Wed, 07 Jan 2004 09:18:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeETc-0004ew-00 for tsvwg@ietf.org; Wed, 07 Jan 2004 09:16:05 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1AeERj-0004RG-00 for tsvwg@ietf.org; Wed, 07 Jan 2004 09:14:07 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 9133977A6FA; Wed, 7 Jan 2004 09:13:35 -0500 (EST) To: tsvwg@ietf.org Cc: faber@isi.edu From: Mark Allman Reply-To: mallman@icir.org Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Fat Bottom Girls Date: Wed, 07 Jan 2004 09:13:35 -0500 Message-Id: <20040107141335.9133977A6FA@guns.icir.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Tsvwg] proposed TCPM charter Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi folks! Happy New Year! As discussed in the tsvwg meeting in Minneapolis several folks have been chatting about starting a new WG to focus on TCP modifications and minor changes. This is mostly an effort to offload work from tsvwg and to sharpen the focus on that work. Ted Faber and I have worked with the TSV ADs to come up with a possible charter that is attached to this message. We'd love to hear any feedback folk might have on how to make the charter better. Thanks! allman --- TCP Maintenance and Minor Extensions (TCPM) Working Group Description: TCP is currently the Internet's predominant transport protocol. To maintain TCP's utility the IETF has regularly updated both the protocol itself and the congestion control algorithms implemented by the protocol that are crucial for the stability of the Internet. These changes reflect our evolving understanding of transport protocols, congestion control and new needs presented by an ever-changing network. The TCPM WG will provide a venue within the IETF to work on these issues. The WG will serve several purposes: * The WG will mostly focus on maintenance issues (e.g., bug fixes) and modest changes to the protocol and algorithms that maintain TCP's utility. * The WG will be a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). TCPM will take a subset of the work which has been conducted in the Transport Area WG over the past several years. Specifically, some of the WG's initial work will be moved from the Transport Area WG (tsvwg). TCPM is expected to be the working group within the IETF to handle TCP changes. Proposals for additional TCP work items should be brought up within the working group. While fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) should be brought through TCPM, it is expected that such large changes will ultimately be handled by the Transport Area WG (tsvwg). All additional work items for TCPM will, naturally, require the approval of the Transport Services Area Area Directors and the IESG. TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP and (in some cases) DCCP). In addition, the IETF has recently worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents in the future will determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. Specific Goals: * A revision of RFC 1323 based on experience and evaluation. Depending on the conclusions of the WG and the nature of the updates this document could be a candidate for Draft Standard. A current Internet-Draft has been submitted to start this process (draft-jacobson-tsvwg-1323bis-00.txt). * A "roadmap" for TCP. The protocol and associated algorithms have become spread out throughout the RFC series. This WG will issue a document that catalogs all the various TCP specifications and informational documents in the RFC series in a single location. An initial discussion (and strawman start at a list of such RFCs) has been conducted on the end2end interest list. * While there is no consensus on exactly how to deal with spurious retransmits (caused by bad RTO estimates or packet reordering) there are several proposals that will be fleshed out in this WG and likely issued as experimental documents. The current set of proposals is: draft-sarolahti-tsvwg-tcp-frto-03.txt draft-blanton-tcp-reordering-00.txt draft-bhandarkar-tcp-dcr-00.txt Milestones: Mar 04 Submit FRTO draft to IESG for publication as an Experimental RFC Mar 04 Submit Reordering Mitigation draft to IESG for publication as an Experimental RFC May 04 Submit DCR draft to IESG for publication as an Experimental RFC May 04 Submit TCP Roadmap document to IESG for publication as a Best Current Practices RFC May 04 Develop (providing editors are available) milestones for advancement to Draft Standard of identified important TCP specs (e.g. RFC 2018, 2581, 2988...). Jun 04 Submit a revision of RFC 1323 to the IESG for publication as a Proposed or Draft Standard (depending on the nature of the changes to the document). _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jan 7 09:25:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11202 for ; Wed, 7 Jan 2004 09:25:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEcK-0005yB-FH for tsvwg-archive@odin.ietf.org; Wed, 07 Jan 2004 09:25:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07EP4K8022920 for tsvwg-archive@odin.ietf.org; Wed, 7 Jan 2004 09:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEcI-0005wt-UA; Wed, 07 Jan 2004 09:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEbU-0005vd-SW for tsvwg@optimus.ietf.org; Wed, 07 Jan 2004 09:24:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11126 for ; Wed, 7 Jan 2004 09:24:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeEbT-00058y-00 for tsvwg@ietf.org; Wed, 07 Jan 2004 09:24:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeEZh-00054e-00 for tsvwg@ietf.org; Wed, 07 Jan 2004 09:22:22 -0500 Received: from [67.38.193.238] (helo=stewart.chicago.il.us) by ietf-mx with esmtp (Exim 4.12) id 1AeEYu-0004yy-00 for tsvwg@ietf.org; Wed, 07 Jan 2004 09:21:33 -0500 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id i07ELPO6091431; Wed, 7 Jan 2004 08:21:26 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3FFC15E5.6010209@stewart.chicago.il.us> Date: Wed, 07 Jan 2004 08:21:25 -0600 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mikael.Latvala@nokia.com CC: Michael.Tuexen@lurchi.franken.de, tsvwg@ietf.org Subject: Re: [Tsvwg] Establishment of SCTP association References: <9B2635C00D654F4CA36B89C22364F0C30154B999@esebe008.ntc.nokia.com> In-Reply-To: <9B2635C00D654F4CA36B89C22364F0C30154B999@esebe008.ntc.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mikael.Latvala@nokia.com wrote: >Michael & Randall, > >Comments: > >1. Linux is one of the operating system to which Michael referred. More specifically, lksctp receives information from kernel's routing service how the packet should be sent (i.e. what source IP address and interface). This routing "cache" entry is attached to the assocation so that this step does not have to be repeated for other packets which belong to the same assocation. > >However, when requesting information from routing service it is possible to tell what is the preferred source IP address. If for some reason this source IP address cannot be used (e.g. interface with which the IP address is associated is down) lksctp is informed of this, and thus can repeat the process using some other valid source IP address. Therefore at least from the Linux point of view, I cannot see that the current implementation would not allow to use the destination IP address of INIT as the source IP address of INIT-ACK. > The above is just one scenario... here is another. Host-A Host-Z IP-1 ---------------||net-isp1 net-isp3||-------IP-3 IP-2 ---------------||net-isp2 net-isp4||-------IP-4 Now Host-A chooses (for whatever reason.. admin etc) a default route of net-isp1. Host-Z chooses a default route of net-isp4.. Both sides bind all addresses. Host-A sends an INIT to IP-3. We choose the default route, and thus pick up the source address IP-1 destination IP-3 and off goes the INIT ----------Src:IP-1---Dest:IP-3(INIT(IP-1,IP-2))-----------------> Host-Z processes the INIT, having a listner it responds to IP-1 out its default route, choosing the best source address for net-isp4 (the default route) which is IP-4. Note that if it did has you request the packet should be ingress-filtered and dropped. <------------------Src:IP-4---Dest:IP-1(INIT-ACK(IP-3,IP-4))---------- This is one of the scenarios that were discussed back when SCTP was developed and the wording you asking to change was discussed... The wording was put in for a VERY SPECIFIC purpose... this one :-> > >2. If we agree that there must a statement along the lines "The source IP address of INIT-ACK must be the same that the destination IP address of INIT.", I do not know what would be the most apprioriate SCTP related draft where this should be inserted. > But no one has agreed with you.. just the opposite.. we have disagreed. Such a choice of wording was discussed and rejected long ago when RFC2960 was being written. The example I gave is just one such that we could probably come up with. The reason it comes to mind is I had a bug in one of the SCTP implementations I am in charge of (not KAME) where an association could not be setup due to this issue (the other impl was not handling looking in the INIT-ACK to find the proper src address).. but anyway you must allow any valid IP address in the src... > >3. RFC3554 (SCTP with IPsec) talks about how IKE can negotiate and associate multiple destination/source IP address pairs with a sigle IPsec SA in Phase 2. It does not address the issue that security administrator must know apriori all the source/destination IP address pair combinations. Perhaps Steve Bellovin et al. where not aware of the fact the source IP address of INIT-ACK is not necessarily equal to the destination IP address of INIT. > No we discussed this... And you have to have all of your addresses know and secured if you are going to do IPSEC between two machines and use those addresses. If for some reason you don't want to have IPSEC on some addresses and IPSEC on the others... you can always do subset binding in the SCTP app to get the IPSEC'd addresses... >Therefore RFC3554 also fails to discuss the issue that negotiation of IP addresses for SA when SCTP is used should happen in two phases. In the first phase apriori known IP addresses are negotiated (hopefully one IP pair per assocation). In the second phase the other IP addresses used in an association are added to the established IPsec SA. The addition of other IP addresses should be transparent to the security administrator. > We had talked about the adding of addresses (which is what you are basically describing above) in the context of add-ip.. and what we concluded (if I remember right) was that you would renegotiate the session starting all over again when an address was added... > >4. Besides the *possible* implementation issues, are there any other reasons why SCTP specs could not mandate that the source IP address of INIT-ACK must be the same than the destination IP address of INIT? After all, no functionality is lost in SCTP even if such a statement is added to the specs. > Other than the fact that you create situations where the routing setup of two random peers will make it so they cannot communicate. We decided long ago that this was not a good thing... If IPSEC needs some addtional things to cover this case then it is a more general problem that needs to be addressed... since any multi-homed protocol will have this same issue. R > >/Mikael > > > > > > > -- 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 From exim@www1.ietf.org Wed Jan 7 10:13:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14286 for ; Wed, 7 Jan 2004 10:13:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeFMn-0008Es-8M for tsvwg-archive@odin.ietf.org; Wed, 07 Jan 2004 10:13:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07FD5SL031667 for tsvwg-archive@odin.ietf.org; Wed, 7 Jan 2004 10:13:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeFMj-0008Do-Fk; Wed, 07 Jan 2004 10:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeFM4-0008CI-Ag for tsvwg@optimus.ietf.org; Wed, 07 Jan 2004 10:12:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14203 for ; Wed, 7 Jan 2004 10:12:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeFM2-00006w-00 for tsvwg@ietf.org; Wed, 07 Jan 2004 10:12:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeFKL-000011-00 for tsvwg@ietf.org; Wed, 07 Jan 2004 10:10:34 -0500 Received: from [67.38.193.238] (helo=stewart.chicago.il.us) by ietf-mx with esmtp (Exim 4.12) id 1AeFIJ-0007j6-00 for tsvwg@ietf.org; Wed, 07 Jan 2004 10:08:28 -0500 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id i07F8IO6091692; Wed, 7 Jan 2004 09:08:19 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3FFC20E2.70601@stewart.chicago.il.us> Date: Wed, 07 Jan 2004 09:08:18 -0600 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org CC: tsvwg@ietf.org, faber@isi.edu Subject: Re: [Tsvwg] proposed TCPM charter References: <20040107141335.9133977A6FA@guns.icir.org> In-Reply-To: <20040107141335.9133977A6FA@guns.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark: It think the charter looks great... any chance that you have finally agreed to chair the group? You have my vote :-> R Mark Allman wrote: > >Hi folks! Happy New Year! > >As discussed in the tsvwg meeting in Minneapolis several folks have been >chatting about starting a new WG to focus on TCP modifications and minor >changes. This is mostly an effort to offload work from tsvwg and to >sharpen the focus on that work. Ted Faber and I have worked with the >TSV ADs to come up with a possible charter that is attached to this >message. We'd love to hear any feedback folk might have on how to make >the charter better. > >Thanks! > >allman > > >--- >TCP Maintenance and Minor Extensions (TCPM) Working Group > >Description: > > TCP is currently the Internet's predominant transport protocol. > To maintain TCP's utility the IETF has regularly updated both > the protocol itself and the congestion control algorithms > implemented by the protocol that are crucial for the stability > of the Internet. These changes reflect our evolving > understanding of transport protocols, congestion control and new > needs presented by an ever-changing network. The TCPM WG will > provide a venue within the IETF to work on these issues. The WG > will serve several purposes: > > * The WG will mostly focus on maintenance issues (e.g., bug > fixes) and modest changes to the protocol and algorithms > that maintain TCP's utility. > > * The WG will be a venue for moving current TCP specifications > along the standards track (as community energy is available > for such efforts). > > TCPM will take a subset of the work which has been conducted in > the Transport Area WG over the past several years. > Specifically, some of the WG's initial work will be moved from > the Transport Area WG (tsvwg). > > TCPM is expected to be the working group within the IETF to > handle TCP changes. Proposals for additional TCP work items > should be brought up within the working group. While > fundamental changes to TCP or its congestion control algorithms > (e.g., departure from loss-based congestion control) should be > brought through TCPM, it is expected that such large changes > will ultimately be handled by the Transport Area WG (tsvwg). > All additional work items for TCPM will, naturally, require the > approval of the Transport Services Area Area Directors and the > IESG. > > TCP's congestion control algorithms are the model followed by > alternate transports (e.g., SCTP and (in some cases) DCCP). In > addition, the IETF has recently worked on several documents > about algorithms that are specified for multiple protocols > (e.g., TCP and SCTP) in the same document. Which WG shepherds > such documents in the future will determined on a case-by-case > basis. In any case, the TCPM WG will remain in close contact > with other relevant WGs working on these protocols to ensure > openness and stringent review from all angles. > >Specific Goals: > > * A revision of RFC 1323 based on experience and evaluation. > Depending on the conclusions of the WG and the nature of the > updates this document could be a candidate for Draft Standard. > A current Internet-Draft has been submitted to start this > process (draft-jacobson-tsvwg-1323bis-00.txt). > > * A "roadmap" for TCP. The protocol and associated algorithms > have become spread out throughout the RFC series. This WG will > issue a document that catalogs all the various TCP > specifications and informational documents in the RFC series in > a single location. An initial discussion (and strawman start at > a list of such RFCs) has been conducted on the end2end interest > list. > > * While there is no consensus on exactly how to deal with spurious > retransmits (caused by bad RTO estimates or packet reordering) > there are several proposals that will be fleshed out in this WG > and likely issued as experimental documents. The current set of > proposals is: > > draft-sarolahti-tsvwg-tcp-frto-03.txt > draft-blanton-tcp-reordering-00.txt > draft-bhandarkar-tcp-dcr-00.txt > >Milestones: > > Mar 04 Submit FRTO draft to IESG for publication as an > Experimental RFC > > Mar 04 Submit Reordering Mitigation draft to IESG for > publication as an Experimental RFC > > May 04 Submit DCR draft to IESG for publication as an > Experimental RFC > > May 04 Submit TCP Roadmap document to IESG for publication as a > Best Current Practices RFC > > May 04 Develop (providing editors are available) milestones for > advancement to Draft Standard of identified important > TCP specs (e.g. RFC 2018, 2581, 2988...). > > Jun 04 Submit a revision of RFC 1323 to the IESG for > publication as a Proposed or Draft Standard (depending > on the nature of the changes to the document). > > >_______________________________________________ >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) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jan 8 08:13:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22132 for ; Thu, 8 Jan 2004 08:13:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZyC-00071b-DE for tsvwg-archive@odin.ietf.org; Thu, 08 Jan 2004 08:13:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08DD4ei026999 for tsvwg-archive@odin.ietf.org; Thu, 8 Jan 2004 08:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZy9-00071F-7A; Thu, 08 Jan 2004 08:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZxd-00070M-SI for tsvwg@optimus.ietf.org; Thu, 08 Jan 2004 08:12:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22102 for ; Thu, 8 Jan 2004 08:12:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeZxc-0001QH-00 for tsvwg@ietf.org; Thu, 08 Jan 2004 08:12:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeZvo-0001LG-00 for tsvwg@ietf.org; Thu, 08 Jan 2004 08:10:37 -0500 Received: from mail-n.franken.de ([193.175.24.27] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AeZuS-0001Gd-00 for tsvwg@ietf.org; Thu, 08 Jan 2004 08:09:12 -0500 Received: from [10.0.1.2] (p5089F539.dip.t-dialin.net [80.137.245.57]) by mail-n.franken.de (Postfix) with ESMTP id 74E45245CA; Thu, 8 Jan 2004 14:08:58 +0100 (CET) In-Reply-To: <3FFC15E5.6010209@stewart.chicago.il.us> References: <9B2635C00D654F4CA36B89C22364F0C30154B999@esebe008.ntc.nokia.com> <3FFC15E5.6010209@stewart.chicago.il.us> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9F5A56B8-41DB-11D8-B24F-000A95C37894@lurchi.franken.de> Content-Transfer-Encoding: 7bit Cc: Mikael.Latvala@nokia.com, tsvwg@ietf.org From: Michael Tuexen Subject: Re: [Tsvwg] Establishment of SCTP association Date: Thu, 8 Jan 2004 14:07:33 +0100 To: "Randall R. Stewart (home)" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mikael, I agree with Randy. See one additoinal comment below. Best regards Michael On 7. Jan 2004, at 15:21 Uhr, Randall R. Stewart (home) wrote: > Mikael.Latvala@nokia.com wrote: > >> Michael & Randall, >> >> Comments: >> >> 1. Linux is one of the operating system to which Michael referred. >> More specifically, lksctp receives information from kernel's routing >> service how the packet should be sent (i.e. what source IP address >> and interface). This routing "cache" entry is attached to the >> assocation so that this step does not have to be repeated for other >> packets which belong to the same assocation. >> >> However, when requesting information from routing service it is >> possible to tell what is the preferred source IP address. If for some >> reason this source IP address cannot be used (e.g. interface with >> which the IP address is associated is down) lksctp is informed of >> this, and thus can repeat the process using some other valid source >> IP address. Therefore at least from the Linux point of view, I cannot >> see that the current implementation would not allow to use the >> destination IP address of INIT as the source IP address of INIT-ACK. >> I was talking about Linux, but not about lksctp. The are more implementations running on linux, the sctplib, for example. This (and others) rely on the kernel to do the source address selection. > > The above is just one scenario... here is another. > > Host-A > Host-Z > > IP-1 ---------------||net-isp1 > net-isp3||-------IP-3 > > IP-2 ---------------||net-isp2 > net-isp4||-------IP-4 > > > Now Host-A chooses (for whatever reason.. admin etc) a default > route of net-isp1. Host-Z chooses a default route of net-isp4.. > Both sides bind all addresses. > > Host-A sends an INIT to IP-3. > > We choose the default route, and thus pick up the source address IP-1 > destination IP-3 > and off goes the INIT > > ----------Src:IP-1---Dest:IP-3(INIT(IP-1,IP-2))-----------------> > > Host-Z processes the INIT, having a listner it responds to IP-1 out its > default route, choosing the best source address for net-isp4 (the > default > route) which is IP-4. Note that if it did has you request the packet > should > be ingress-filtered and dropped. > > <------------------Src:IP-4---Dest:IP-1(INIT-ACK(IP-3,IP-4))---------- > > > This is one of the scenarios that were discussed back when > SCTP was developed and the wording you asking to change was > discussed... The wording was put in for a VERY SPECIFIC purpose... > this one :-> > >> >> 2. If we agree that there must a statement along the lines "The >> source IP address of INIT-ACK must be the same that the destination >> IP address of INIT.", I do not know what would be the most >> apprioriate SCTP related draft where this should be inserted. >> > > But no one has agreed with you.. just the opposite.. we have > disagreed. Such > a choice of wording was discussed and rejected long ago when RFC2960 > was > being written. > > The example I gave is just one such that we could probably come up > with. The > reason it comes to mind is I had a bug in one of the SCTP > implementations I > am in charge of (not KAME) where an association could not be setup due > to this issue (the other impl was not handling looking in the INIT-ACK > to > find the proper src address).. but anyway you must allow any valid > IP address in the src... > >> >> 3. RFC3554 (SCTP with IPsec) talks about how IKE can negotiate and >> associate multiple destination/source IP address pairs with a sigle >> IPsec SA in Phase 2. It does not address the issue that security >> administrator must know apriori all the source/destination IP address >> pair combinations. Perhaps Steve Bellovin et al. where not aware of >> the fact the source IP address of INIT-ACK is not necessarily equal >> to the destination IP address of INIT. > > No we discussed this... And you have to have all of your addresses know > and secured if you are going to do IPSEC between two machines and use > those addresses. If for some reason you don't want to have IPSEC > on some addresses and IPSEC on the others... you can always do > subset binding in the SCTP app to get the IPSEC'd addresses... > > >> Therefore RFC3554 also fails to discuss the issue that negotiation of >> IP addresses for SA when SCTP is used should happen in two phases. In >> the first phase apriori known IP addresses are negotiated (hopefully >> one IP pair per assocation). In the second phase the other IP >> addresses used in an association are added to the established IPsec >> SA. The addition of other IP addresses should be transparent to the >> security administrator. > > We had talked about the adding of addresses (which is what you are > basically describing above) in > the context of add-ip.. and what we concluded (if I remember right) > was that you would renegotiate > the session starting all over again when an address was added... > >> >> 4. Besides the *possible* implementation issues, are there any other >> reasons why SCTP specs could not mandate that the source IP address >> of INIT-ACK must be the same than the destination IP address of INIT? >> After all, no functionality is lost in SCTP even if such a statement >> is added to the specs. >> > > Other than the fact that you create situations where the routing setup > of two > random peers will make it so they cannot communicate. > > We decided long ago that this was not a good thing... > > If IPSEC needs some addtional things to cover this case then it is a > more general problem that needs to be addressed... since any > multi-homed > protocol will have this same issue. > > R > >> >> /Mikael >> >> >> >> >> > > > -- > 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 From exim@www1.ietf.org Thu Jan 8 08:26:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22363 for ; Thu, 8 Jan 2004 08:26:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeaAn-0007PI-5t for tsvwg-archive@odin.ietf.org; Thu, 08 Jan 2004 08:26:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08DQ5EK028391 for tsvwg-archive@odin.ietf.org; Thu, 8 Jan 2004 08:26:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeaAk-0007ML-4o; Thu, 08 Jan 2004 08:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZG5-0003zs-Pq for tsvwg@optimus.ietf.org; Thu, 08 Jan 2004 07:27:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19600 for ; Thu, 8 Jan 2004 07:27:28 -0500 (EST) From: Mikael.Latvala@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeZG0-0005m5-00 for tsvwg@ietf.org; Thu, 08 Jan 2004 07:27:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeZDB-0005cO-00 for tsvwg@ietf.org; Thu, 08 Jan 2004 07:24:30 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AeZ7V-0005OY-00 for tsvwg@ietf.org; Thu, 08 Jan 2004 07:18:37 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i08CIB610095 for ; Thu, 8 Jan 2004 14:18:11 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 8 Jan 2004 14:17:40 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 8 Jan 2004 14:17:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] Establishment of SCTP association Date: Thu, 8 Jan 2004 14:17:40 +0200 Message-ID: <9B2635C00D654F4CA36B89C22364F0C30154B99B@esebe008.ntc.nokia.com> Thread-Topic: [Tsvwg] Establishment of SCTP association Thread-Index: AcPVKabKowR8dwpXQWObOXBK9g65rwAsOzug To: Cc: , X-OriginalArrivalTime: 08 Jan 2004 12:17:40.0235 (UTC) FILETIME=[68FE25B0:01C3D5E1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Randall, Based on the scenario you presented and assuming that both hosts have 2 = network interfaces Host-A has at least the following entries in its = routing table Destination Gateway Iface 0.0.0.0 ips1-router eth0 #IP-1 assigned to = interface eth0 ips4-subnet ips2-router eth1 #IP-2 assgined to = interface eth1=20 Host-Z's routing table looks like Destination Gateway Iface 0.0.0.0 ips4-router eth0 #IP-4 assigned to = interface eth0 ips1-subnet ips3-router eth1 #IP-3 assgined to = interface eth1=20 Without the second entry in both routing tables, administrator would = have to manually reconfigure the routing table in case eth0 fails. How = else host would know where to send the IP packet after an interface = failure? (Or are you assuming that in case of an interface failure there = is some magic script which removes the old void default route entry and = adds a new one?) So, when host-Z sends INIT-ACK back it is going to choose eth1 (IP-3 as = source IP address) because of the longest prefix match rule. Not eth0 as = you stated.=20 Host-Z's routing entries could be in other order where host-Z's default = route is ips3 Destination Gateway Iface 0.0.0.0 ips3-router eth0 #IP-3 assigned to = interface eth0 ips2-subnet ips4-router eth1 #IP-4 assgined to = interface eth1=20 But this would not change the situation as IP-3 would be still chosen as = the source IP address. Obviously having separate routing entries for each and every possible = subnet is not very practical. Therefore the use of multiple routing = tables when multi-homing is used makes lots of sense. In that case each = routing table would have a default route entry. The selection of the = routing table would be based on the source IP address. Which also = guarantees that scenarios like you, Randall, presented would not happen, = i.e. IP packet would be sent through IPS' subnet but the IP packet's = source IP address did not come from the IPS' subnet thus causing the = packet to be filtered. /Mikael >=20 > Host-A =20 > =20 > Host-Z >=20 > IP-1 ---------------||net-isp1 =20 > net-isp3||-------IP-3 >=20 > IP-2 ---------------||net-isp2 =20 > net-isp4||-------IP-4 >=20 >=20 > Now Host-A chooses (for whatever reason.. admin etc) a default > route of net-isp1. Host-Z chooses a default route of net-isp4.. > Both sides bind all addresses. >=20 > Host-A sends an INIT to IP-3. >=20 > We choose the default route, and thus pick up the source address IP-1=20 > destination IP-3 > and off goes the INIT >=20 > ----------Src:IP-1---Dest:IP-3(INIT(IP-1,IP-2))-----------------> > =20 >=20 > Host-Z processes the INIT, having a listner it responds to=20 > IP-1 out its > default route, choosing the best source address for net-isp4=20 > (the default > route) which is IP-4. Note that if it did has you request the=20 > packet should > be ingress-filtered and dropped. >=20 > <------------------Src:IP-4---Dest:IP-1(INIT-ACK(IP-3,IP-4))---------- >=20 >=20 > This is one of the scenarios that were discussed back when > SCTP was developed and the wording you asking to change was > discussed... The wording was put in for a VERY SPECIFIC=20 > purpose... this=20 > one :-> >=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jan 8 08:41:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22952 for ; Thu, 8 Jan 2004 08:41:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeaPN-0008ON-3y for tsvwg-archive@odin.ietf.org; Thu, 08 Jan 2004 08:41:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Df99e032253 for tsvwg-archive@odin.ietf.org; Thu, 8 Jan 2004 08:41:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeaPF-0008NJ-LY; Thu, 08 Jan 2004 08:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeaP2-0008ML-6h for tsvwg@optimus.ietf.org; Thu, 08 Jan 2004 08:40:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22897 for ; Thu, 8 Jan 2004 08:40:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeaOo-0002od-00 for tsvwg@ietf.org; Thu, 08 Jan 2004 08:40:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeaMr-0002eE-00 for tsvwg@ietf.org; Thu, 08 Jan 2004 08:38:35 -0500 Received: from mail-n.franken.de ([193.175.24.27] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AeaKD-0002Oj-00 for tsvwg@ietf.org; Thu, 08 Jan 2004 08:35:49 -0500 Received: from [10.0.1.2] (p5089F403.dip.t-dialin.net [80.137.244.3]) by mail-n.franken.de (Postfix) with ESMTP id 7F4B8245CF; Thu, 8 Jan 2004 14:35:25 +0100 (CET) In-Reply-To: <9B2635C00D654F4CA36B89C22364F0C30154B99B@esebe008.ntc.nokia.com> References: <9B2635C00D654F4CA36B89C22364F0C30154B99B@esebe008.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5145A639-41DF-11D8-B24F-000A95C37894@lurchi.franken.de> Content-Transfer-Encoding: 7bit Cc: , From: Michael Tuexen Subject: Re: [Tsvwg] Establishment of SCTP association Date: Thu, 8 Jan 2004 14:34:00 +0100 To: X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 8. Jan 2004, at 13:17 Uhr, wrote: Mikael, assume host 1 has a route for 10.1.1.0/16 through eth0 (10.1.1.1/24) and 10.2.0.0/16 through eth1 (10.2.1.1/24). Furthermore host 2 has only one interface 10.1.2.1 and a default route to eth0 (10.1.2.1/24). Assume that the default router of host 2 has connectivity to both routers used by host 1. If host 2 sends a INIT to host 1 using 10.1.1.1 as distination address host 1 will send back the INIT-ACK to 10.1.2.1 and 10.1.1.1 as source address. Everything is fine. But if host 2 sends the INIT to host 1 using 10.2.1.1 as destination address host 1 wil send back the INIT-ACK to 10.1.2.1 using eth0 and therefore would choose 10.1.1.1 as a source address of the INIT-ACK. Using your rule the association could not be established in this scenario. You do not have redundancy here, but that is clear. But is is important to accept INIT-ACK from addresses not being the destination address of the INIT. You could say the host 1 could use the other address still using the router but the router may do ingress filtering. Best regards Michael > Randall, > > Based on the scenario you presented and assuming that both hosts have > 2 network interfaces Host-A has at least the following entries in its > routing table > > Destination Gateway Iface > 0.0.0.0 ips1-router eth0 #IP-1 assigned to > interface eth0 > ips4-subnet ips2-router eth1 #IP-2 assgined to > interface eth1 > > Host-Z's routing table looks like > > Destination Gateway Iface > 0.0.0.0 ips4-router eth0 #IP-4 assigned to > interface eth0 > ips1-subnet ips3-router eth1 #IP-3 assgined to > interface eth1 > > Without the second entry in both routing tables, administrator would > have to manually reconfigure the routing table in case eth0 fails. How > else host would know where to send the IP packet after an interface > failure? (Or are you assuming that in case of an interface failure > there is some magic script which removes the old void default route > entry and adds a new one?) > > So, when host-Z sends INIT-ACK back it is going to choose eth1 (IP-3 > as source IP address) because of the longest prefix match rule. Not > eth0 as you stated. > > Host-Z's routing entries could be in other order where host-Z's > default route is ips3 > > Destination Gateway Iface > 0.0.0.0 ips3-router eth0 #IP-3 assigned to > interface eth0 > ips2-subnet ips4-router eth1 #IP-4 assgined to > interface eth1 > > But this would not change the situation as IP-3 would be still chosen > as the source IP address. > > Obviously having separate routing entries for each and every possible > subnet is not very practical. Therefore the use of multiple routing > tables when multi-homing is used makes lots of sense. In that case > each routing table would have a default route entry. The selection of > the routing table would be based on the source IP address. Which also > guarantees that scenarios like you, Randall, presented would not > happen, i.e. IP packet would be sent through IPS' subnet but the IP > packet's source IP address did not come from the IPS' subnet thus > causing the packet to be filtered. > > /Mikael > >> >> Host-A >> >> Host-Z >> >> IP-1 ---------------||net-isp1 >> net-isp3||-------IP-3 >> >> IP-2 ---------------||net-isp2 >> net-isp4||-------IP-4 >> >> >> Now Host-A chooses (for whatever reason.. admin etc) a default >> route of net-isp1. Host-Z chooses a default route of net-isp4.. >> Both sides bind all addresses. >> >> Host-A sends an INIT to IP-3. >> >> We choose the default route, and thus pick up the source address IP-1 >> destination IP-3 >> and off goes the INIT >> >> ----------Src:IP-1---Dest:IP-3(INIT(IP-1,IP-2))-----------------> >> >> >> Host-Z processes the INIT, having a listner it responds to >> IP-1 out its >> default route, choosing the best source address for net-isp4 >> (the default >> route) which is IP-4. Note that if it did has you request the >> packet should >> be ingress-filtered and dropped. >> >> <------------------Src:IP-4---Dest:IP-1(INIT-ACK(IP-3,IP-4))---------- >> >> >> This is one of the scenarios that were discussed back when >> SCTP was developed and the wording you asking to change was >> discussed... The wording was put in for a VERY SPECIFIC >> purpose... this >> one :-> >> > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jan 8 09:15:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22362 for ; Thu, 8 Jan 2004 08:26:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeaAn-0007Ok-3h for tsvwg-archive@odin.ietf.org; Thu, 08 Jan 2004 08:26:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08DQ4Ag028392 for tsvwg-archive@odin.ietf.org; Thu, 8 Jan 2004 08:26:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeaAj-0007Lw-0v; Thu, 08 Jan 2004 08:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeE6M-0003id-Kb for tsvwg@optimus.ietf.org; Wed, 07 Jan 2004 08:52:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09218 for ; Wed, 7 Jan 2004 08:52:00 -0500 (EST) From: Mikael.Latvala@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeE6L-00035s-00 for tsvwg@ietf.org; Wed, 07 Jan 2004 08:52:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeE4T-00032D-00 for tsvwg@ietf.org; Wed, 07 Jan 2004 08:50:06 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AeE31-0002zV-00 for tsvwg@ietf.org; Wed, 07 Jan 2004 08:48:35 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i07DmX412121 for ; Wed, 7 Jan 2004 15:48:33 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 7 Jan 2004 15:48:32 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 15:48:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] Establishment of SCTP association Date: Wed, 7 Jan 2004 15:48:32 +0200 Message-ID: <9B2635C00D654F4CA36B89C22364F0C30154B999@esebe008.ntc.nokia.com> Thread-Topic: [Tsvwg] Establishment of SCTP association Thread-Index: AcPT6h/P/r8exRTgRey/cTUlWbpWrQBMxnbw To: , Cc: X-OriginalArrivalTime: 07 Jan 2004 13:48:33.0361 (UTC) FILETIME=[F0E56410:01C3D524] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Michael & Randall, Comments: 1. Linux is one of the operating system to which Michael referred. More = specifically, lksctp receives information from kernel's routing service = how the packet should be sent (i.e. what source IP address and = interface). This routing "cache" entry is attached to the assocation so = that this step does not have to be repeated for other packets which = belong to the same assocation. However, when requesting information from routing service it is possible = to tell what is the preferred source IP address. If for some reason this = source IP address cannot be used (e.g. interface with which the IP = address is associated is down) lksctp is informed of this, and thus can = repeat the process using some other valid source IP address. Therefore = at least from the Linux point of view, I cannot see that the current = implementation would not allow to use the destination IP address of INIT = as the source IP address of INIT-ACK. 2. If we agree that there must a statement along the lines "The source = IP address of INIT-ACK must be the same that the destination IP address = of INIT.", I do not know what would be the most apprioriate SCTP related = draft where this should be inserted. 3. RFC3554 (SCTP with IPsec) talks about how IKE can negotiate and = associate multiple destination/source IP address pairs with a sigle = IPsec SA in Phase 2. It does not address the issue that security = administrator must know apriori all the source/destination IP address = pair combinations. Perhaps Steve Bellovin et al. where not aware of the = fact the source IP address of INIT-ACK is not necessarily equal to the = destination IP address of INIT. Therefore RFC3554 also fails to discuss = the issue that negotiation of IP addresses for SA when SCTP is used = should happen in two phases. In the first phase apriori known IP = addresses are negotiated (hopefully one IP pair per assocation). In the = second phase the other IP addresses used in an association are added to = the established IPsec SA. The addition of other IP addresses should be = transparent to the security administrator.=20 4. Besides the *possible* implementation issues, are there any other = reasons why SCTP specs could not mandate that the source IP address of = INIT-ACK must be the same than the destination IP address of INIT? After = all, no functionality is lost in SCTP even if such a statement is added = to the specs. /Mikael > -----Original Message----- > From: ext Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] > Sent: Tuesday, January 06, 2004 2:13 AM > To: Latvala Mikael (Nokia-NET/Helsinki) > Cc: tsvwg@ietf.org > Subject: Re: [Tsvwg] Establishment of SCTP association >=20 >=20 > Mikael, >=20 > see my comments below. >=20 > Best regards > Michael >=20 > On 29. Dec 2003, at 9:50 Uhr, Mikael.Latvala@nokia.com wrote: >=20 > > Michael, > > > > I agree, that true man-in-middle can do lots of harm at the=20 > transport=20 > > layer. However, association highjack is definately the worst one. > > > > If you want to use IPsec against such attacks, configuring IPsec=20 > > becomes in no time mission impossible, if INIT-ACK's source=20 > IP address=20 > > can be different than INIT's destination IP address. Simple=20 > because if=20 > > this is allowed, person configuring IPsec policy database must know=20 > > before hand any IP address that the peer may use in an SCTP=20 > > assocation. > > > > However, if INIT-ACK's source IP address would be always=20 > the same than=20 > > INIT's destination IP address, then person in charge of configuring=20 > > IPsec policy database would have to know only one IP address. The=20 > > other additional IP addresses negotiated during and possibly after=20 > > SCTP association setup could be dynamically added to the=20 > IPsec policy=20 > > database. > > > I agree with you that if one peer has n addresses and the other m the=20 > person has to set up 2 * n * m SAs and he must know > all addresses before the association is set up. > The problem in requiring the source address of the INIT-ACk=20 > is the same=20 > as the destination address of the INIT is not > so simple to fulfill. If the SCTP stack does not control the source=20 > address by itself but relies on the kernel to do > that based on the routing table then you can not guarantee that. If=20 > have seen several implementations working like this. > > Obviously one could use wildcard in a source selector field=20 > in IPsec=20 > > policy database. Unfortunately there are plenty of companies who do=20 > > not approve such security policy. > > > > Therefore I am requesting that SCTP implementor's guide and/or SCTP=20 > > dynamic address recofiguration documents discuss about this problem=20 > > and explicitly forbid any SCTP implementation from using IP=20 > address in=20 > > INIT-ACK that is different from INIT's destination IP address. > > > Are you talking about plain SCTP (RFC 2960) or the ADDIP ID.=20 > The AddIP=20 > ID will be updated with additional security > mechanisms. > > /Mikael > > > >> -----Original Message----- > >> From: ext Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] > >> Sent: Saturday, December 20, 2003 2:03 PM > >> To: Latvala Mikael (NET/Helsinki) > >> Cc: tsvwg@ietf.org > >> Subject: Re: [Tsvwg] Establishment of SCTP association > >> > >> > >> Mikael, > >> > >> a true man-in-middle can do everything: insert ABORTs when he > >> wants and > >> so on. > >> And not allowing that the other IP address is used as a > >> source address > >> does not > >> hel you. The true man in the middle can intercept the packet > >> and return > >> the > >> INIT-ACK with B's address as a source address. In general: a true > >> man-in-the-middle > >> can do everything and there is not much a transport layer=20 > can do. You > >> must > >> have some mechanism to identify your peer not based on the IP > >> address. > >> Possibilities > >> include IPSec or TLS. > >> > >> Best regards > >> Michael > >> > >> > >> On 17. Dec 2003, at 16:33 Uhr, Mikael.Latvala@nokia.com wrote: > >> > >>> Hello, > >>> > >>> We noticed an interesting behaviour in Linux SCTP implementation. > >>> > >>> 1. Endpoint A sends an INIT chunk to endpoint B using IPa > >> as a source > >>> IP address and IPb as a destination IP address > >>> > >>> 2. Endpoint B returns INIT ACK to endpoint A using IPc as a > >> source IP > >>> address and IPa as a destination IP address. IPb is > >> included in INIT > >>> ACK as an address parameter. > >>> > >>> 3. A and B finish the association negotiation, endpoint A > >> using IPb as > >>> its primary IP address and endpoint B using IPc as a=20 > source address > >>> when it sends data chunks to endpoint A. > >>> > >>> My question is: although RFRC2960 does not explicitly deny > >> the use of > >>> IPc as a source IP address in INIT ACK, when implementation > >> does so, > >>> doesn't this present a security hole in the association setup > >>> procedure? Therefore such behaviour should not be allowed. > >>> > >>> For example, in a man-in-the-middle attack hostile node > >> could highjack > >>> the association by responding to INIT, which endpoint A > >> sent, faster > >>> than endpoint B, using hostile node's own IP address IPz as > >> a source > >>> IP address. Obviously this attack assumes that the endpoint > >> A selects > >>> the source IP address IPz as its primary IP address. > >>> > >>> /Mikael > >>> > >>> _______________________________________________ > >>> tsvwg mailing list > >>> tsvwg@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/tsvwg > >>> > >> > >> > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > > >=20 >=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jan 8 09:34:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24220 for ; Thu, 8 Jan 2004 09:34:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebEZ-00023e-B5 for tsvwg-archive@odin.ietf.org; Thu, 08 Jan 2004 09:34:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08EY3Nd007904 for tsvwg-archive@odin.ietf.org; Thu, 8 Jan 2004 09:34:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebEX-00023K-4t; Thu, 08 Jan 2004 09:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebDq-00022d-0Z for tsvwg@optimus.ietf.org; Thu, 08 Jan 2004 09:33:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24179 for ; Thu, 8 Jan 2004 09:33:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AebDg-0005Vu-00 for tsvwg@ietf.org; Thu, 08 Jan 2004 09:33:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AebBB-0005NY-00 for tsvwg@ietf.org; Thu, 08 Jan 2004 09:30:34 -0500 Received: from [67.38.193.238] (helo=stewart.chicago.il.us) by ietf-mx with esmtp (Exim 4.12) id 1Aeb5i-00058E-00 for tsvwg@ietf.org; Thu, 08 Jan 2004 09:24:54 -0500 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id i08EOTO6099322; Thu, 8 Jan 2004 08:24:30 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3FFD681D.6050809@stewart.chicago.il.us> Date: Thu, 08 Jan 2004 08:24:29 -0600 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mikael.Latvala@nokia.com CC: Michael.Tuexen@lurchi.franken.de, tsvwg@ietf.org Subject: Re: [Tsvwg] Establishment of SCTP association References: <9B2635C00D654F4CA36B89C22364F0C30154B99B@esebe008.ntc.nokia.com> In-Reply-To: <9B2635C00D654F4CA36B89C22364F0C30154B99B@esebe008.ntc.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mikael.Latvala@nokia.com wrote: >Randall, > >Based on the scenario you presented and assuming that both hosts have 2 network interfaces Host-A has at least the following entries in its routing table > >Destination Gateway Iface >0.0.0.0 ips1-router eth0 #IP-1 assigned to interface eth0 >ips4-subnet ips2-router eth1 #IP-2 assgined to interface eth1 > >Host-Z's routing table looks like > >Destination Gateway Iface >0.0.0.0 ips4-router eth0 #IP-4 assigned to interface eth0 >ips1-subnet ips3-router eth1 #IP-3 assgined to interface eth1 > >Without the second entry in both routing tables, administrator would have to manually reconfigure the routing table in case eth0 fails. How else host would know where to send the IP packet after an interface failure? (Or are you assuming that in case of an interface failure there is some magic script which removes the old void default route entry and adds a new one?) > >So, when host-Z sends INIT-ACK back it is going to choose eth1 (IP-3 as source IP address) because of the longest prefix match rule. Not eth0 as you stated. > > I never said anything about assigning specific routes to isp3-subnet/isp1-subnet as you describe above.. Most systems do NOT have specific routes to various sub-nets. Take a look at most machines and you will find only one default route period. Now you can, in linux and with KAME-mpath, get multiple default routes. But you will only end up using the first route (until the first one fails). So lets go back to my diagram: Host-A Host-Z IP-1 ---------------||net-isp1 net-isp3||-------IP-3 IP-2 ---------------||net-isp2 net-isp4||-------IP-4 Invision a big cloud between all the ISP's and Host-A and Host-Z are just two random hosts that communicate upon the internet.. there network admin's have no idea that today for what ever reason the two will talk.. they just happen to.. maybe a new employee joins and decides to converse with an ole friend :-> The routing tables for Host-A may look like: Internet: Destination Gateway default isp -1 isp-2/24 link#1 Or if multi-path is in paly you might see: Internet: Destination Gateway default isp-1 default isp-2 But our Host-A would NOT have any sort of route in for isp-3 or isp-4. This is the environment that SCTP must work in.. not something pre-configured. In the multi-path case SCTP needs to be able to ask the routing system when it thinks there is problems with an endpoint something like rt_find_alternate(dest, old-route); instead of the typcial rt_alloc(dst) call... I.e. to be effective with default routes the routing system needs a method to query it for an different route to the same place (if such exists). We implemented this in KAME and it works quite nicely..... >Host-Z's routing entries could be in other order where host-Z's default route is ips3 > >Destination Gateway Iface >0.0.0.0 ips3-router eth0 #IP-3 assigned to interface eth0 >ips2-subnet ips4-router eth1 #IP-4 assgined to interface eth1 > >But this would not change the situation as IP-3 would be still chosen as the source IP address. > Sorry.. the above is NOT how the routing tables would look. You would have NO specific entyr to ips2-subnet... > >Obviously having separate routing entries for each and every possible subnet is not very practical. > Exactly.. you have to deal with one default.. and possibly multipe defaults as well... >Therefore the use of multiple routing tables when multi-homing is used makes lots of sense. In that case each routing table would have a default route entry. > Or MULTIPLE default routes.. linux as allowed this for a long time.. not that I they have any interface to use this besides the first outbound route interface failing completely.... at least back last time I looked... which as been some time.. The point is multiple defaults are something I think we will see as bandwidth and connections get cheaper... > The selection of the routing table would be based on the source IP address. Which also guarantees that scenarios like you, Randall, presented would not happen, > Source based routing is still a research item and only shows up in some limited places (I think ISP's sometimes have this for example). We do not select destination routes using the source address... not yet.. > i.e. IP packet would be sent through IPS' subnet but the IP packet's source IP address did not come from the IPS' subnet thus causing the packet to be filtered. > Which is exactly all of my points.. it just seems you are not making the connection... As I stated.. this was discussed in much detail when SCTP was created... you can go back and check the mailing list archives if you would like.. I also have even more email than that stashed away somewhere... Basically there are specific reasons why the source address may NOT be where the packet was sent on either the INIT or INIT-ACK.. this is ok.. the protocol allows for it by design. R > >/Mikael > > > >>Host-A >> >> Host-Z >> >>IP-1 ---------------||net-isp1 >>net-isp3||-------IP-3 >> >>IP-2 ---------------||net-isp2 >>net-isp4||-------IP-4 >> >> >>Now Host-A chooses (for whatever reason.. admin etc) a default >>route of net-isp1. Host-Z chooses a default route of net-isp4.. >>Both sides bind all addresses. >> >>Host-A sends an INIT to IP-3. >> >>We choose the default route, and thus pick up the source address IP-1 >>destination IP-3 >>and off goes the INIT >> >>----------Src:IP-1---Dest:IP-3(INIT(IP-1,IP-2))-----------------> >> >> >>Host-Z processes the INIT, having a listner it responds to >>IP-1 out its >>default route, choosing the best source address for net-isp4 >>(the default >>route) which is IP-4. Note that if it did has you request the >>packet should >>be ingress-filtered and dropped. >> >><------------------Src:IP-4---Dest:IP-1(INIT-ACK(IP-3,IP-4))---------- >> >> >>This is one of the scenarios that were discussed back when >>SCTP was developed and the wording you asking to change was >>discussed... The wording was put in for a VERY SPECIFIC >>purpose... this >>one :-> >> >> >> > > > > > -- Randall R. Stewart 815-477-2127 (office) 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jan 16 14:43:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26395 for ; Fri, 16 Jan 2004 14:43:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZs4-00079b-QW for tsvwg-archive@odin.ietf.org; Fri, 16 Jan 2004 14:43:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GJh8on027458 for tsvwg-archive@odin.ietf.org; Fri, 16 Jan 2004 14:43:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZrx-00078k-4U; Fri, 16 Jan 2004 14:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWtw-0002f3-3j for tsvwg@optimus.ietf.org; Fri, 16 Jan 2004 11:32:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20485 for ; Fri, 16 Jan 2004 11:32:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhWtu-0006mZ-00 for tsvwg@ietf.org; Fri, 16 Jan 2004 11:32:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhWsw-0006f8-00 for tsvwg@ietf.org; Fri, 16 Jan 2004 11:31:51 -0500 Received: from mail.poliba.it ([193.204.49.50]) by ietf-mx with esmtp (Exim 4.12) id 1AhWs9-0006YE-00 for tsvwg@ietf.org; Fri, 16 Jan 2004 11:31:01 -0500 Received: from deectl18 (deectl18.poliba.it [193.204.59.114]) by mail.poliba.it (8.11.6/8.11.6) with SMTP id i0GGXIw32081; Fri, 16 Jan 2004 17:33:19 +0100 Message-ID: <010a01c3dc4e$0d89cb80$723bccc1@poliba.it> From: "Saverio Mascolo" To: , References: <2846497B437BF84BAD1A4CC407418D2604193A37@exchange1.slac.stanford.edu> Date: Fri, 16 Jan 2004 17:30:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] TCP Westwood+ Linux kernel 2.4 patches Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit We have made available patches of TCP Westwood+ Linux kernel 2.4 at http://buffer.antifork.org/westwood/westwood.html sm ----------- Saverio Mascolo, Ph.D Associate Professor Dipartimento di Elettrotecnica ed Elettronica, Politecnico di Bari Via Orabona 4, 70125 Bari, Italy email: mascolo@poliba.it tel. +39 080 5963621 fax. +39 080 5963410 http://www-dee.poliba.it/dee-web/Personale/mascolo.html _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jan 22 05:33:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15935 for ; Thu, 22 Jan 2004 05:33:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajc97-00081U-0o for tsvwg-archive@odin.ietf.org; Thu, 22 Jan 2004 05:33:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MAX83Q030839 for tsvwg-archive@odin.ietf.org; Thu, 22 Jan 2004 05:33:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajc8z-0007yo-26; Thu, 22 Jan 2004 05:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajc8n-0007xm-JY for tsvwg@optimus.ietf.org; Thu, 22 Jan 2004 05:32:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15929 for ; Thu, 22 Jan 2004 05:32:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajc8k-0002Xr-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 05:32:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajc7o-0002WF-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 05:31:49 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1Ajc7E-0002UN-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 05:31:12 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id i0MAV7rN013535; Thu, 22 Jan 2004 19:31:08 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id i0MAV7qY013412; Thu, 22 Jan 2004 19:31:07 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.10/8.12.10) with ESMTP id i0MAV6GD024872; Thu, 22 Jan 2004 19:31:06 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.10/8.12.10) with ESMTP id i0MAV60V024866; Thu, 22 Jan 2004 19:31:06 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id i0MAV50r019570; Thu, 22 Jan 2004 19:31:06 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id TAA09325; Thu, 22 Jan 2004 19:31:05 +0900 (JST) Received: from morita-vaiodtop.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id TAA27971; Thu, 22 Jan 2004 19:31:05 +0900 (JST) Message-Id: <5.1.1.11.2.20040122183427.045b2c60@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5 Date: Thu, 22 Jan 2004 19:32:46 +0900 To: "Geib, Ruediger" From: "MORITA, Naotaka" Cc: tsvwg@ietf.org In-Reply-To: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB781@G8PQD.blf01.telek om.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: PPS: influence of route changes Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ruediger, Thank you for your interesting question. I thought I have missed to join the discussion, when you raised such issue. At 09:57 04/01/22 +0100, Geib, Ruediger wrote: >Dear Naotaka, > >accounting for the influence of route changes to me is an >open issue with respect to PPS. What happens after a route >change is that some routers recognise a sudden increase in >High Subclass traffic without prior Middle Subclass traffic >(others notice a sudden decrease). I had already considered the situation, and my current idea is, if the router operates as a static mode, which has the common bandwidth threshold for both High and Middle, it must be a problem. If it operates as a elastic mode, it is not a problem, because it exceptionally passes High class. As you know, in the elastic mode, the router has two threshold, one is BWm, e.g. 40Mbps, and anther is BWh, e.g. 80Mbps. When the sum is more than BWm, and if Middle packets are there, they are discarded, but all High packets can pass upto BWh. This is what I want to write in section 3.2.2 in the definition of MF-PHB. > >If service quality should not suffer from this effect, >resources must be overprovisioned prior to its occurence. >If resources are to be re-provisioned as a consequence of a >route change, a rather fast signaling protocol is required. >This protocol must further accurately determine the >resources required. That sounds complex and it may >spoil the "state free" benefits of pps. Yes, it is a kind of overprovisioning. But, no, it is still state free. In the above example, the link would be 100Mbps and up to 40Mbps can be used in normal operation. In the case of route change, the link can tolerate upto 80Mbps with High class. The values of 40Mbps and 80Mbps are configured and no signalling is necessary. Off course, it can not tolerate more than double traffic, but it is a matter of network engineering. If I carefully design the network, it is not a problem I believe. This concept can easilly be exteded when MF-PHB is applied to MPLS network. The issue of my proposed approach is how to avoid the accumulation of the exceptional traffic. For the sake of simplicity, let's assume 1 to 1 protection. Phase (link A, link B) #1 ( 0, 0) #2 ( 30, 20) #3 ( 40, 40) further session attempt fails Link A is broken #4 ( x , 80) Link A is recovered instantaneously. #5 ( 10, 75) Link A is broken again. #6 ( x , 85) **** now 5 Mbps high packets will be discarded. I am now investigating such scenario and examine it by the real router in February. > >Assuming overprovisioned High Subclass resources as a solution, >which value is added by an information on route change >occurences? It doesn't decrease the load, it only helps to >distinguish the effect of a route change from a DoS attack or >other kinds of misuse. I'm not sure whether PPS is a reasonable >architecture if it allows for DoS attacks and other kinds of ************* >misuse. So excluding this cause for a spontaneous load increase, >the load increase itself indicates a route change. A ************ >node will discard Middle Subclass traffic for a while. What it >further may do is marking High Subclass Traffic by something >as ECN. Many voice and video codecs are able to decrease >sending rate. After a while, "normal" operation is resumed and >these ECN marks dissapear. > >What are your thoughts about how to deal with route changes in >a PPS network? > >Regards, Rudiger I sorry but I do not understand the two lines between *****. Yes, DoS is an issue of PPS, but as is described in the framework draft, I assume two protecting point: edge router and media monitor server. Initially, I do not think path coupled signaling for PPS. But it is another intersting topic how to apply NSIS to measurement based admission control. ---------------------------------- Naotaka MORITA, NTT _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jan 22 14:52:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06691 for ; Thu, 22 Jan 2004 14:52:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajks1-0004Rs-4d for tsvwg-archive@odin.ietf.org; Thu, 22 Jan 2004 14:52:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MJq4wg017073 for tsvwg-archive@odin.ietf.org; Thu, 22 Jan 2004 14:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajkrx-0004QJ-Ty; Thu, 22 Jan 2004 14:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajkr4-0004Oz-6y for tsvwg@optimus.ietf.org; Thu, 22 Jan 2004 14:51:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06638 for ; Thu, 22 Jan 2004 14:51:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajkr1-0006Ph-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 14:51:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajkq1-00056u-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 14:50:02 -0500 Received: from mail-n.franken.de ([193.175.24.27] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1Ajkpf-0004aJ-00; Thu, 22 Jan 2004 14:49:39 -0500 Received: from [10.0.1.3] (p5089DD04.dip.t-dialin.net [80.137.221.4]) by mail-n.franken.de (Postfix) with ESMTP id 466EC2462D; Thu, 22 Jan 2004 20:48:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: sigtran@ietf.org, tsvwg@ietf.org From: Michael Tuexen Date: Thu, 22 Jan 2004 20:47:40 +0100 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] 7th SCTP Interop Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, the 7th SCTP Interop will be hosted by the University of Applied Sciences in Muenster, Germany. It will start on July 25th and will end on July 30th. It is the week before the summer IETF. In addition to the testbed we have used in previous Interops (support of dual homed hosts, IPv4 and IPv6, delay, loss, jitter) we will also provide a switched GBit Ethernet network for performance testing and a simulated satellite link with middle boxes generating packet drop reports. Tested specifications include RFC 2960 with RFC 3309, SCTP-IG, PR-SCTP, ADD-IP, PKT-DRP-REP and possibly more. I would like to know who is interested in attending the Interop to finalize my planning because we have to charge some money to cover the costs. We also have to make sure that we have enough electric power in the room. Therefore I would like to know - which companies would like to attend - the number of participants of each company - how many computers (laptop, desktop, ...) and switches / hubs each company will bring in. Please send your response to tuexen@fh-muenster.de After having an initial guess about the number of participants I will set up a website with the information regarding registration, fee, hotel, traveling, ... you need. If you have any questions do not hesitate to contact me. Thank you very much for your cooperation. Best regards Michael _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jan 22 16:37:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12302 for ; Thu, 22 Jan 2004 16:37:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmVe-0004Nr-Mm for tsvwg-archive@odin.ietf.org; Thu, 22 Jan 2004 16:37:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MLb57d016755 for tsvwg-archive@odin.ietf.org; Thu, 22 Jan 2004 16:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmVb-0004Lx-S0; Thu, 22 Jan 2004 16:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajdsa-0005Yq-Op for tsvwg@optimus.ietf.org; Thu, 22 Jan 2004 07:24:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18650 for ; Thu, 22 Jan 2004 07:24:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajdsa-0007Ia-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 07:24:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajdmw-0006XW-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 07:18:22 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1Ajdin-00064D-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 07:14:05 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id i0MCDbrN013953 for ; Thu, 22 Jan 2004 21:13:37 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id i0MCDbqY005006 for ; Thu, 22 Jan 2004 21:13:37 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.10/8.12.10) with ESMTP id i0MCDaGD008133 for ; Thu, 22 Jan 2004 21:13:36 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.10/8.12.10) with ESMTP id i0MCDa0V008130 for ; Thu, 22 Jan 2004 21:13:36 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id i0MCDY0r023685 for ; Thu, 22 Jan 2004 21:13:34 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id VAA16820 for ; Thu, 22 Jan 2004 21:13:33 +0900 (JST) Received: from morita-vaiodtop.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id VAA04788 for ; Thu, 22 Jan 2004 21:13:33 +0900 (JST) Message-Id: <5.1.1.11.2.20040122211512.045eb7a8@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5 Date: Thu, 22 Jan 2004 21:15:03 +0900 To: tsvwg@ietf.org From: "Geib, Ruediger" (by way of "MORITA, Naotaka" ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] RE: PPS: influence of route changes Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Naotaka, thanks for your fast reply. I think we agree on the best way to deal with route changes in a pps architecture. Some comments and a clarification in line. Regards, Rudiger ----snip---- |In the above example, the link would be 100Mbps and |up to 40Mbps can be used in normal operation. |In the case of route change, |the link can tolerate upto 80Mbps with High class. |The values of 40Mbps and 80Mbps are configured and no |signalling is necessary. |Off course, it can not tolerate more than double traffic, |but it is a matter of network engineering. |If I carefully design the network, it is not a problem I believe. I fully agree. |This concept can easilly be exteded when MF-PHB is applied to |MPLS network. Yes. Another benefit of pps. ------snip-------------- The following section just should say that DoS attacks and other misuse aren't expected to be an issue for PPS. To clarify this, I've argued from an opposite viewpoint: if attacks and misuse were an issue for pps, nobody would deploy it. | >. I'm not sure whether PPS is a reasonable | >architecture if it allows for DoS attacks and other kinds of |************* | >misuse. So excluding this cause for a spontaneous load increase, | >the load increase itself indicates a route change. A |************ | >node will discard Middle Subclass traffic for a while. What it | >further may do is marking High Subclass Traffic by something | >as ECN. Many voice and video codecs are able to decrease | >sending rate. After a while, "normal" operation is resumed and | >these ECN marks dissapear. |I sorry but I do not understand the two lines between *****. | |Yes, DoS is an issue of PPS, but as is described in the |framework draft, I assume two protecting point: edge router and |media monitor server. ---snip------- ---------------------------------- Naotaka MORITA, Senior Research Engineer, Supervisor Network Service Systems Laboratories Information Sharing Laboratory Group NTT 3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 E-mail: morita.naotaka@lab.ntt.co.jp _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jan 22 16:37:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12313 for ; Thu, 22 Jan 2004 16:37:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmVf-0004OW-AO for tsvwg-archive@odin.ietf.org; Thu, 22 Jan 2004 16:37:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MLb6pd016803 for tsvwg-archive@odin.ietf.org; Thu, 22 Jan 2004 16:37:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmVc-0004M5-UB; Thu, 22 Jan 2004 16:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajl24-0006ih-V9 for tsvwg@optimus.ietf.org; Thu, 22 Jan 2004 15:02:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06958 for ; Thu, 22 Jan 2004 15:02:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajl1s-0004qL-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 15:02:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajl00-0002Od-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 15:00:21 -0500 Received: from mail-n.franken.de ([193.175.24.27] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1Ajkyf-0000Gj-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 14:58:57 -0500 Received: from [10.0.1.3] (p5089DD04.dip.t-dialin.net [80.137.221.4]) by mail-n.franken.de (Postfix) with ESMTP id 5586D2464C for ; Thu, 22 Jan 2004 20:58:08 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <1DDEE015-4D15-11D8-8713-000A95C37894@micmac.franken.de> Content-Type: text/plain; charset=US-ASCII; format=flowed To: tsvwg@ietf.org From: Michael Tuexen Date: Thu, 22 Jan 2004 20:56:49 +0100 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] 7th SCTP Interop Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, the 7th SCTP Interop will be hosted by the University of Applied Sciences in Muenster, Germany. It will start on July 25th and will end on July 30th. It is the week before the summer IETF. In addition to the testbed we have used in previous Interops (support of dual homed hosts, IPv4 and IPv6, delay, loss, jitter) we will also provide a switched GBit Ethernet network for performance testing and a simulated satellite link with middle boxes generating packet drop reports. Tested specifications include RFC 2960 with RFC 3309, SCTP-IG, PR-SCTP, ADD-IP, PKT-DRP-REP and possibly more. I would like to know who is interested in attending the Interop to finalize my planning because we have to charge some money to cover the costs. We also have to make sure that we have enough electric power in the room. Therefore I would like to know - which companies would like to attend - the number of participants of each company - how many computers (laptop, desktop, ...) and switches / hubs each company will bring in. Please send your response to tuexen@fh-muenster.de After having an initial guess about the number of participants I will set up a website with the information regarding registration, fee, hotel, traveling, ... you need. If you have any questions do not hesitate to contact me. Thank you very much for your cooperation. Best regards Michael _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jan 22 16:37:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12317 for ; Thu, 22 Jan 2004 16:37:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmVf-0004O1-11 for tsvwg-archive@odin.ietf.org; Thu, 22 Jan 2004 16:37:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MLb5TS016759 for tsvwg-archive@odin.ietf.org; Thu, 22 Jan 2004 16:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmVY-0004Kp-Uc; Thu, 22 Jan 2004 16:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjamV-0003ZA-Pb for tsvwg@optimus.ietf.org; Thu, 22 Jan 2004 04:05:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14186 for ; Thu, 22 Jan 2004 04:05:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjamT-0007Y6-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 04:05:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjalV-0007WS-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 04:04:41 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1Ajal1-0007Ts-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 04:04:11 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Thu, 22 Jan 2004 09:57:58 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Jan 2004 09:57:58 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB781@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: morita.naotaka@lab.ntt.co.jp Cc: tsvwg@ietf.org Date: Thu, 22 Jan 2004 09:57:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Tsvwg] PPS: influence of route changes Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Dear Naotaka, accounting for the influence of route changes to me is an open issue with respect to PPS. What happens after a route change is that some routers recognise a sudden increase in High Subclass traffic without prior Middle Subclass traffic (others notice a sudden decrease). If service quality should not suffer from this effect, resources must be overprovisioned prior to its occurence. If resources are to be re-provisioned as a consequence of a route change, a rather fast signaling protocol is required. This protocol must further accurately determine the resources required. That sounds complex and it may spoil the "state free" benefits of pps. Assuming overprovisioned High Subclass resources as a solution, which value is added by an information on route change occurences? It doesn't decrease the load, it only helps to distinguish the effect of a route change from a DoS attack or other kinds of misuse. I'm not sure whether PPS is a reasonable architecture if it allows for DoS attacks and other kinds of misuse. So excluding this cause for a spontaneous load increase, the load increase itself indicates a route change. A node will discard Middle Subclass traffic for a while. What it further may do is marking High Subclass Traffic by something as ECN. Many voice and video codecs are able to decrease sending rate. After a while, "normal" operation is resumed and these ECN marks dissapear. What are your thoughts about how to deal with route changes in a PPS network? Regards, Rudiger _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jan 22 17:26:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12309 for ; Thu, 22 Jan 2004 16:37:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmVe-0004NY-JY for tsvwg-archive@odin.ietf.org; Thu, 22 Jan 2004 16:37:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MLb5Cf016750 for tsvwg-archive@odin.ietf.org; Thu, 22 Jan 2004 16:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmVa-0004LR-Ey; Thu, 22 Jan 2004 16:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajcy5-00026I-Dt for tsvwg@optimus.ietf.org; Thu, 22 Jan 2004 06:25:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16915 for ; Thu, 22 Jan 2004 06:25:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajcy1-0004Gb-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 06:25:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajcx5-0004Eo-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 06:24:47 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AjcwS-0004BL-00 for tsvwg@ietf.org; Thu, 22 Jan 2004 06:24:08 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Thu, 22 Jan 2004 12:20:31 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Jan 2004 12:20:30 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB783@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: morita.naotaka@lab.ntt.co.jp Cc: tsvwg@ietf.org Date: Thu, 22 Jan 2004 12:20:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Tsvwg] RE: PPS: influence of route changes Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Naotaka, thanks for your fast reply. I think we agree on the best way to deal with route changes in a pps architecture. Some comments and a clarification in line. Regards, Rudiger ----snip---- |In the above example, the link would be 100Mbps and |up to 40Mbps can be used in normal operation. |In the case of route change, |the link can tolerate upto 80Mbps with High class. |The values of 40Mbps and 80Mbps are configured and no |signalling is necessary. |Off course, it can not tolerate more than double traffic, |but it is a matter of network engineering. |If I carefully design the network, it is not a problem I believe. I fully agree. |This concept can easilly be exteded when MF-PHB is applied to |MPLS network. Yes. Another benefit of pps. ------snip-------------- The following section just should say that DoS attacks and other misuse aren't expected to be an issue for PPS. To clarify this, I've argued from an opposite viewpoint: if attacks and misuse were an issue for pps, nobody would deploy it. | >. I'm not sure whether PPS is a reasonable | >architecture if it allows for DoS attacks and other kinds of |************* | >misuse. So excluding this cause for a spontaneous load increase, | >the load increase itself indicates a route change. A |************ | >node will discard Middle Subclass traffic for a while. What it | >further may do is marking High Subclass Traffic by something | >as ECN. Many voice and video codecs are able to decrease | >sending rate. After a while, "normal" operation is resumed and | >these ECN marks dissapear. |I sorry but I do not understand the two lines between *****. | |Yes, DoS is an issue of PPS, but as is described in the |framework draft, I assume two protecting point: edge router and |media monitor server. ---snip------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jan 28 11:09:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06771 for ; Wed, 28 Jan 2004 11:09:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlsFU-0007Ge-Ki for tsvwg-archive@odin.ietf.org; Wed, 28 Jan 2004 11:09:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SG94WS027932 for tsvwg-archive@odin.ietf.org; Wed, 28 Jan 2004 11:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlsFR-0007FT-0L; Wed, 28 Jan 2004 11:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlsEl-00078f-0b for tsvwg@optimus.ietf.org; Wed, 28 Jan 2004 11:08:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06708; Wed, 28 Jan 2004 11:08:13 -0500 (EST) Message-Id: <200401281608.LAA06708@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: tsvwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 28 Jan 2004 11:08:13 -0500 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-prsctp-03.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : SCTP Partial Reliability Extension Author(s) : R. Stewart Filename : draft-ietf-tsvwg-prsctp-03.txt Pages : 23 Date : 2004-1-27 This memo describes an extension to the Stream Control Transmission Protocol (SCTP) RFC2960 [5] that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes (1) the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type (2) one example partially reliable service that can be provided to the upper layer via this mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-prsctp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-prsctp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-prsctp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-prsctp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112925.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jan 28 12:48:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16666 for ; Wed, 28 Jan 2004 12:48:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AltnR-0000yN-Hs for tsvwg-archive@odin.ietf.org; Wed, 28 Jan 2004 12:48:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SHmDcC003733 for tsvwg-archive@odin.ietf.org; Wed, 28 Jan 2004 12:48:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AltnF-0000xC-Fp; Wed, 28 Jan 2004 12:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Altmx-0000vC-Na for tsvwg@optimus.ietf.org; Wed, 28 Jan 2004 12:47:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16638 for ; Wed, 28 Jan 2004 12:47:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Altmw-0005Ov-00 for tsvwg@ietf.org; Wed, 28 Jan 2004 12:47:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Altm8-0005KG-00 for tsvwg@ietf.org; Wed, 28 Jan 2004 12:46:53 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1AltlU-0005Bw-00 for tsvwg@ietf.org; Wed, 28 Jan 2004 12:46:12 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 87A9677A6F9 for ; Wed, 28 Jan 2004 12:45:38 -0500 (EST) To: tsvwg@ietf.org From: Mark Allman Reply-To: mallman@icir.org Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Street Fighting Man Date: Wed, 28 Jan 2004 12:45:38 -0500 Message-Id: <20040128174538.87A9677A6F9@guns.icir.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Tsvwg] The IESG: WG Review: TCP Maintenance and Minor Extensions (tcpm) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , fyi ------- Forwarded Message From: The IESG To: IETF-Announce: ; Cc: new-work@ietf.org Subject: WG Review: TCP Maintenance and Minor Extensions (tcpm) Date: Wed, 28 Jan 2004 11:53:50 -0500 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by February 4th. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- Current Status: Proposed Working Group Description: TCP is currently the Internet's predominant transport protocol. To maintain TCP's utility the IETF has regularly updated both the protocol itself and the congestion control algorithms implemented by the protocol that are crucial for the stability of the Internet. These changes reflect our evolving understanding of transport protocols, congestion control and new needs presented by an ever-changing network. The TCPM WG will provide a venue within the IETF to work on these issues. The WG will serve several purposes: * The WG will mostly focus on maintenance issues (e.g., bug fixes) and modest changes to the protocol and algorithms that maintain TCP's utility. * The WG will be a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). * The WG will write a document that outlines "what is TCP". This document will be a roadmap of sorts to the various TCP specifications in the RFC series. TCPM will take a subset of the work which has been conducted in the Transport Area WG over the past several years. Specifically, some of the WG's initial work will be moved from the Transport Area WG (tsvwg). TCPM is expected to be the working group within the IETF to handle TCP changes. Proposals for additional TCP work items should be brought up within the working group. While fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) should be brought through TCPM, it is expected that such large changes will ultimately be handled by the Transport Area WG (tsvwg). All additional work items for TCPM will, naturally, require the approval of the Transport Services Area Area Directors and the IESG. TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP and (in some cases) DCCP). In addition, the IETF has recently worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents in the future will determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. ------- End of Forwarded Message _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jan 29 13:56:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07806 for ; Thu, 29 Jan 2004 13:56:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHKj-0005AR-Ld for tsvwg-archive@odin.ietf.org; Thu, 29 Jan 2004 13:56:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TIu9DL019857 for tsvwg-archive@odin.ietf.org; Thu, 29 Jan 2004 13:56:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHKd-000569-6u; Thu, 29 Jan 2004 13:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHK5-00051z-Pi for tsvwg@optimus.ietf.org; Thu, 29 Jan 2004 13:55:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07677 for ; Thu, 29 Jan 2004 13:55:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmHK3-0007ah-00 for tsvwg@ietf.org; Thu, 29 Jan 2004 13:55:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmHJ5-0007U5-00 for tsvwg@ietf.org; Thu, 29 Jan 2004 13:54:28 -0500 Received: from mail.vsnl.co.in ([202.54.117.12] helo=HQ-SMTP.vsnl.co.in) by ietf-mx with esmtp (Exim 4.12) id 1AmHIE-0007Hu-00 for tsvwg@ietf.org; Thu, 29 Jan 2004 13:53:35 -0500 Received: from mail pickup service by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC; Fri, 30 Jan 2004 00:29:42 +0530 Received: from asgard.ietf.org ([132.151.6.40]) by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Jan 2004 22:49:13 +0530 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AlsFv-00073y-Dx for ietf-announce-list@asgard.ietf.org; Wed, 28 Jan 2004 11:09:31 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AlsEj-0006vF-3I for all-ietf@asgard.ietf.org; Wed, 28 Jan 2004 11:08:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06708; Wed, 28 Jan 2004 11:08:13 -0500 (EST) Message-Id: <200401281608.LAA06708@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: tsvwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 28 Jan 2004 11:08:13 -0500 Precedence: bulk X-OriginalArrivalTime: 28 Jan 2004 17:19:15.0109 (UTC) FILETIME=[DAA3CD50:01C3E5C2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-prsctp-03.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : SCTP Partial Reliability Extension Author(s) : R. Stewart Filename : draft-ietf-tsvwg-prsctp-03.txt Pages : 23 Date : 2004-1-27 This memo describes an extension to the Stream Control Transmission Protocol (SCTP) RFC2960 [5] that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes (1) the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type (2) one example partially reliable service that can be provided to the upper layer via this mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-prsctp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-prsctp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-prsctp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-prsctp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112925.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg