From tsvwg-bounces@ietf.org Sat Oct 01 06:32:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELef8-0001sP-OE; Sat, 01 Oct 2005 06:32:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELef7-0001rh-CE for tsvwg@megatron.ietf.org; Sat, 01 Oct 2005 06:32:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20453 for ; Sat, 1 Oct 2005 06:32:10 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELen9-0001u1-Io for tsvwg@ietf.org; Sat, 01 Oct 2005 06:40:32 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j91AVsEV009801; Sat, 1 Oct 2005 06:31:56 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <433E659A.9070906@stewart.chicago.il.us> Date: Sat, 01 Oct 2005 06:31:54 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Tsvwg] ICMP issue with SCTP IG References: <20050923153212.A25158@openss7.org> <43382B9E.20002@stewart.chicago.il.us> <20050926111501.B27273@openss7.org> <20050927163526.D12632@openss7.org> <20050927234627.B16994@openss7.org> <61bc9bec27220ddbb93d36da04074962@lurchi.franken.de> <20050928014829.B18411@openss7.org> <433A9778.6080704@stewart.chicago.il.us> <20050928110748.D23449@openss7.org> In-Reply-To: <20050928110748.D23449@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Brian F. G. Bidulock wrote: > Randall, > > Segment number does not monotonically increase. But that makes no difference in this case.. since as you stated.. if I remember this thread right ... the "attacker" will be able to know enough about the app its getting to send data so it can 'predict' what the segments are going to be ... in TSN's. This is the same for TCP then.. instead of perdicting X bytes per TSN.. it changes the scaling.. thats all. So you end up with the same attack. I think that if you are really that concerned about this type of attack (I am not) then you need to join SCTP into the TCP document that illustrated the same attack and work with those authors to see if you can get adjustments made to both TCP and SCTP .. since they both have the same problem.. I will see if I can't go dig around in my other email account and find the draft name so then you can get in touch with those authors... R > > --brian > > On Wed, 28 Sep 2005, Randall Stewart wrote: > > >>Brian F. G. Bidulock wrote: >> >>>Michael, >>> >>>On Wed, 28 Sep 2005, Michael Tuexen wrote: >>> >>> >>> >>>>>The purpose of the HB[nonce] is not to verify the IP addresss (it >>>>>belongs to the peer) but to verify the that the peer actually received >>>>>the data for which he is sending SACKs, and that he hasn't sent SACKs >>>>>for data in advance of reception just to increase the server's cwnd and >>>>>cause him to saturate his outgoing interfaces. >>>> >>>>OK. I understand now what your HB(nonce) is for. >>>>But this is pretty different from the goal of the path verification >>>>procedure. >>>>I think it is enough to >>>>- verify that an address really belongs to the peer (using the path >>>> verification) >>>>- make sending SACKs acking data not yet received as hard as possible >>>> by requiring the SHOULD for sending an ABORT on reception of a SACK >>>> for unsent data. >>>> >>>>I do not think that there is a need of requiring an authentication for >>>>SACKs. If the receiver does not bundle the HB-ACK(nonce) with the >>>>SACK you might run into problems when packets are reordered in the >>>>network. >>> >>> >>>No worse than SACKs getting lost by the network (which is the more >>>common of the two events), and if reordered SACKs turn into lost SACKs >>>that is not much of a concern. >>> >>>I agree with the SHOULD on cumulative acks beyond sent DATA, but don't >>>think that it will make sending bogus SACKs that difficult at all. >>> >>>By controlling arwnd in the bogus SACKs, it is probably possible to >>>predict exactly how many TSNs you will send: starting small and ramping >>>arwnd up just a little slower than cwnd would grow. >>> >>>Then the TSNs sacked could be what the attacker just received, plus the >>>number of TSNs in the ramp up, minus a few (or a bunch) so that you will >>>never ABORT as a result of them being too high. It does not matter, the >>>minus a few (or a bunch) will only affect initial RTT calculations, cwnd >>>can still grow unbounded. >>> >>>Sounds like a good demonstration for DoS attack points at the next SCTP >>>interop. >>> >> >>And tell me how TCP is different please? >> >>R >> >> >> >>>--brian >>> >> >> >>-- >>Randall Stewart >>803-345-0369 815-342-5222(cell) > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sat Oct 01 06:50:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELewW-0007xH-FB; Sat, 01 Oct 2005 06:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELewU-0007lz-3T for tsvwg@megatron.ietf.org; Sat, 01 Oct 2005 06:50:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25970 for ; Sat, 1 Oct 2005 06:50:06 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELf4W-0002Ow-DR for tsvwg@ietf.org; Sat, 01 Oct 2005 06:58:29 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j91Ao7EV009861; Sat, 1 Oct 2005 06:50:08 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <433E69DF.8020204@stewart.chicago.il.us> Date: Sat, 01 Oct 2005 06:50:07 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] SCTP IG: Reception of bundled chunks References: <20050927164910.E12632@openss7.org> <20050927235449.C16994@openss7.org> <045c9893b4e3790e7b5c111ad2194ab5@lurchi.franken.de> In-Reply-To: <045c9893b4e3790e7b5c111ad2194ab5@lurchi.franken.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: bidulock@openss7.org, "'tsvwg@ietf.org'" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael: Why not something more along the lines of: ---------------------------------------------------------- When a packet containing multiple control or DATA chunks is received and the processing of the packet requires the sending of multiple chunks in response. The sender of the response chunk('s) MUST NOT send more than one packet. If bundling is supported multiple response chunks that fit into a single packet may be bundled together into one single response packet. If bundling is NOT supported then the sender MUST send only one response chunk and MUST discard all other responses. Note that this rule does NOT apply to a SACK chunk since a SACK chunk is, in itself, a response to DATA and a SACK does not require a response of more DATA. -------------------------------------------------------- I think the above would handle all the cases you list below yours.. and yet at the same time allows the exception case for the DATA/SACK.. since really a SACK does NOT require a response. Note: wordsmithing welcome on the above.. I will no go get some more coffee.. and think about the HB.verification wording :-D R Michael Tuexen wrote: > Hi Brian, > > here is a text suggestion. > > The following could be added to section 6.10. > > When a packet containing multiple control chunks or DATA > chunks which results in sending of an ERROR chunk is received > and the processing of the packet requires the sending of multiple > chunks no more than one packet MUST be sent. If bundling is > supported multiple chunks that fit into one packet can be put > into the packet. All other chunks MUST be discarded. If bundling > is not supported, only the first chunk can be sent back. > > Should we also have some examples: Reception of > - multiple HB > - multiple unknown chunks > - multiple SHUTDOWN-ACKs > - DATA with errors in fields > - multiple COOKIE-ECHOs > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sat Oct 01 07:24:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELfU7-0007JW-6o; Sat, 01 Oct 2005 07:24:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELfU5-0007JR-Jg for tsvwg@megatron.ietf.org; Sat, 01 Oct 2005 07:24:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26854 for ; Sat, 1 Oct 2005 07:24:50 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[992hzFpR3JuQ67wyNHuIP6uBDWVpm6dC]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELfc7-00038t-W2 for tsvwg@ietf.org; Sat, 01 Oct 2005 07:33:13 -0400 Received: from ns.pigworks.openss7.net (IDENT:e9OOy6YVecntXWKvcPIgUeN4IgqJjuqE@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j91BOkc14706; Sat, 1 Oct 2005 05:24:46 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j91BOkw03715; Sat, 1 Oct 2005 05:24:46 -0600 Date: Sat, 1 Oct 2005 05:24:46 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Subject: Re: [Tsvwg] SCTP IG: Reception of bundled chunks Message-ID: <20051001052446.A3698@openss7.org> References: <20050927164910.E12632@openss7.org> <20050927235449.C16994@openss7.org> <045c9893b4e3790e7b5c111ad2194ab5@lurchi.franken.de> <433E69DF.8020204@stewart.chicago.il.us> 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: <433E69DF.8020204@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Sat, Oct 01, 2005 at 06:50:07AM -0400 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 j91BOkc14706 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: Michael Tuexen , "'tsvwg@ietf.org'" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randall, That sounds good too. --brian On Sat, 01 Oct 2005, Randall Stewart wrote: > Michael: >=20 > Why not something more along the lines of: > ---------------------------------------------------------- > When a packet containing multiple control or DATA chunks > is received and the processing of the packet > requires the sending of multiple chunks in > response. The sender of the response chunk('s) MUST NOT send > more than one packet. If bundling is supported > multiple response chunks that fit into a single packet may > be bundled together into one single response packet. If bundling > is NOT supported then the sender MUST send only one response > chunk and MUST discard all other responses. Note that this > rule does NOT apply to a SACK chunk since a SACK chunk > is, in itself, a response to DATA and a SACK does not > require a response of more DATA. > -------------------------------------------------------- >=20 > I think the above would handle all the cases you > list below yours.. and yet at the same time > allows the exception case for the DATA/SACK.. > since really a SACK does NOT require a response. >=20 > Note: wordsmithing welcome on the above.. I will no go > get some more coffee.. and think about the HB.verification > wording :-D >=20 > R >=20 > Michael Tuexen wrote: > > Hi Brian, > >=20 > > here is a text suggestion. > >=20 > > The following could be added to section 6.10. > >=20 > > When a packet containing multiple control chunks or DATA > > chunks which results in sending of an ERROR chunk is received > > and the processing of the packet requires the sending of multiple > > chunks no more than one packet MUST be sent. If bundling is > > supported multiple chunks that fit into one packet can be put > > into the packet. All other chunks MUST be discarded. If bundling > > is not supported, only the first chunk can be sent back. > >=20 > > Should we also have some examples: Reception of > > - multiple HB > > - multiple unknown chunks > > - multiple SHUTDOWN-ACKs > > - DATA with errors in fields > > - multiple COOKIE-ECHOs > >=20 >=20 >=20 > --=20 > Randall Stewart > 803-345-0369 815-342-5222(cell) --=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 tsvwg-bounces@ietf.org Sat Oct 01 07:29:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELfYr-0004bI-Kj; Sat, 01 Oct 2005 07:29:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELfYp-0004Zw-9G for tsvwg@megatron.ietf.org; Sat, 01 Oct 2005 07:29:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26971 for ; Sat, 1 Oct 2005 07:29:43 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[1ZsB+Zz4lKnjbPICkb8ctJtIX5XxSH4U]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELfgs-0003Eb-Us for tsvwg@ietf.org; Sat, 01 Oct 2005 07:38:07 -0400 Received: from ns.pigworks.openss7.net (IDENT:1/EZZ30MNhWlTSRmfF5sV72+zfnx+WVD@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j91BT0c14951; Sat, 1 Oct 2005 05:29:01 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j91BT0L03761; Sat, 1 Oct 2005 05:29:00 -0600 Date: Sat, 1 Oct 2005 05:29:00 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051001052900.B3698@openss7.org> References: <20050926111501.B27273@openss7.org> <20050927163526.D12632@openss7.org> <20050927234627.B16994@openss7.org> <61bc9bec27220ddbb93d36da04074962@lurchi.franken.de> <20050928014829.B18411@openss7.org> <433A9778.6080704@stewart.chicago.il.us> <20050928110748.D23449@openss7.org> <433E659A.9070906@stewart.chicago.il.us> 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: <433E659A.9070906@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Sat, Oct 01, 2005 at 06:31:54AM -0400 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 j91BT0c14951 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randall, I suppose it is not all that much more difficult. I think that most servers worried about this throttle to a portion of the outoing bandwidth anyway. But IMO it is not something that the application should protect against but is the obligation of the transport. I would be interested in joining the draft if someone can pass its name along. --brian On Sat, 01 Oct 2005, Randall Stewart wrote: > Brian F. G. Bidulock wrote: > > Randall, > >=20 > > Segment number does not monotonically increase. >=20 > But that makes no difference in this case.. since as you > stated.. if I remember this thread right ... the > "attacker" will be able to know enough about the > app its getting to send data so it can 'predict' > what the segments are going to be ... in TSN's. > This is the same for TCP then.. instead of perdicting > X bytes per TSN.. it changes the scaling.. thats all. >=20 > So you end up with the same attack. >=20 > I think that if you are really that concerned about this > type of attack (I am not) then you need to join SCTP > into the TCP document that illustrated the same attack > and work with those authors to see if you can get > adjustments made to both TCP and SCTP .. since they > both have the same problem.. >=20 > I will see if I can't go dig around in my > other email account and find the draft name so then > you can get in touch with those authors... >=20 > R >=20 --=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 tsvwg-bounces@ietf.org Sat Oct 01 14:58:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELmZX-0003yK-Ts; Sat, 01 Oct 2005 14:58:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELmZU-0003yC-1x for tsvwg@megatron.ietf.org; Sat, 01 Oct 2005 14:58:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13884 for ; Sat, 1 Oct 2005 14:58:51 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELmhb-0005LL-Ez for tsvwg@ietf.org; Sat, 01 Oct 2005 15:07:19 -0400 Received: from [192.168.1.10] (p5481EC79.dip.t-dialin.net [84.129.236.121]) by ilsa.franken.de (Postfix) with ESMTP id 5A8FB245CC; Sat, 1 Oct 2005 20:58:41 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <433E69DF.8020204@stewart.chicago.il.us> References: <20050927164910.E12632@openss7.org> <20050927235449.C16994@openss7.org> <045c9893b4e3790e7b5c111ad2194ab5@lurchi.franken.de> <433E69DF.8020204@stewart.chicago.il.us> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <68d8485abfda95ae573a4c0956cbce6f@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] SCTP IG: Reception of bundled chunks Date: Sat, 1 Oct 2005 20:57:52 +0200 To: Randall Stewart X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: bidulock@openss7.org, "'tsvwg@ietf.org'" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randy, some minor changes: When a packet containing multiple control or DATA chunks is received and the processing of the packet requires the sending of multiple chunks in response, the sender of the response chunk('s) MUST NOT send more than one packet. If bundling is supported multiple response chunks that fit into a single packet MAY be bundled together into one single response packet. If bundling is not supported then the sender MUST NOT send more than one response chunk and MUST discard all other responses. Note that this rule does NOT apply to a SACK chunk since a SACK chunk is, in itself, a response to DATA and a SACK does not require a response of more DATA. And then a question: What is the intention of the last sentence? What is allowed to send back when you receive HB,UNKOWN,DATA,DATA[param error]? If the receiver supports bundling, it can send back a packet containing HB-ACK, ERROR, SACK, ERROR if it fits. I would assume that only a HB-ACK is sent back, when the receiver of the packet does not support bundling? Best regards Michael On Oct 1, 2005, at 12:50 Uhr, Randall Stewart wrote: > Michael: > > Why not something more along the lines of: > ---------------------------------------------------------- > When a packet containing multiple control or DATA chunks > is received and the processing of the packet > requires the sending of multiple chunks in > response. The sender of the response chunk('s) MUST NOT send > more than one packet. If bundling is supported > multiple response chunks that fit into a single packet may > be bundled together into one single response packet. If bundling > is NOT supported then the sender MUST send only one response > chunk and MUST discard all other responses. Note that this > rule does NOT apply to a SACK chunk since a SACK chunk > is, in itself, a response to DATA and a SACK does not > require a response of more DATA. > -------------------------------------------------------- > > I think the above would handle all the cases you > list below yours.. and yet at the same time > allows the exception case for the DATA/SACK.. > since really a SACK does NOT require a response. > > Note: wordsmithing welcome on the above.. I will no go > get some more coffee.. and think about the HB.verification > wording :-D > > R > > Michael Tuexen wrote: >> Hi Brian, >> here is a text suggestion. >> The following could be added to section 6.10. >> When a packet containing multiple control chunks or DATA >> chunks which results in sending of an ERROR chunk is received >> and the processing of the packet requires the sending of multiple >> chunks no more than one packet MUST be sent. If bundling is >> supported multiple chunks that fit into one packet can be put >> into the packet. All other chunks MUST be discarded. If bundling >> is not supported, only the first chunk can be sent back. >> Should we also have some examples: Reception of >> - multiple HB >> - multiple unknown chunks >> - multiple SHUTDOWN-ACKs >> - DATA with errors in fields >> - multiple COOKIE-ECHOs > > > -- > Randall Stewart > 803-345-0369 815-342-5222(cell) > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sat Oct 01 15:10:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELmkh-0008Nz-Ut; Sat, 01 Oct 2005 15:10:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELmkg-0008Lv-5d for tsvwg@megatron.ietf.org; Sat, 01 Oct 2005 15:10:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14782 for ; Sat, 1 Oct 2005 15:10:26 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELmsn-0005d4-Mx for tsvwg@ietf.org; Sat, 01 Oct 2005 15:18:54 -0400 Received: from [192.168.1.10] (p5481EC79.dip.t-dialin.net [84.129.236.121]) by ilsa.franken.de (Postfix) with ESMTP id 41D17245DF; Sat, 1 Oct 2005 21:10:26 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <433D2D18.8090509@stewart.chicago.il.us> References: <20050923143323.B22938@openss7.org> <20050923153212.A25158@openss7.org> <43382B9E.20002@stewart.chicago.il.us> <20050927163118.B12632@openss7.org> <20050927234315.A16994@openss7.org> <91bb78e5eac14f6e9588078a2233551e@lurchi.franken.de> <20050928012527.A18411@openss7.org> <20050929164043.B7159@openss7.org> <433D2D18.8090509@stewart.chicago.il.us> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Sat, 1 Oct 2005 21:09:40 +0200 To: Randall Stewart X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit Cc: bidulock@openss7.org, tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randy, see my comments in-line. Best regards Michael On Sep 30, 2005, at 14:18 Uhr, Randall Stewart wrote: > Brian/Michael: > > Ok, still not having written the text :-) > > Let me summarize what I think the outcome is for this thread on > HB's and verfication. > > a) We will have a new variable HB.max.burst > b) This will be set to a default of 1. > c) It will be used during path verification after > association startup... to validate other addresses. > d) We will also allow an alternative, where instead of > doing path verification by starting a timer, instead Up to here everything is clear and agreed (I think) > we will allow a HB+Nonce bundled with data. Only one > packet may be outstanding in this case until after > the HB+nonce is responded to.. and thus the path > verified.. This is an 'optimization' Brian wants to do (which is OK). > > One note that Jana and I have discussed in this past week > (and this IMO is NOT something that needs to be in the I-G), > is that the sender of the INIT could verify two addresses > of the peer. > > Consider > > INIT ---to:IP-A---> > <---INIT-ACK(IP-A, IP-B) > A-Verified > ----COOKIE-ECHO-to:IP-B-> > <----COOKIE-ACK > B-Verified No. B is not verified. The COOKIE-ACK is too simple to spoof. > > At the end of the above, two paths are verified (IP-A and IP-B). Now > if the above is not good enough (since the COOKIE-ACK could be > forged by the server) one could do: > ----COOKIE-ECHO,HB/nonce-to:IP-B-> > <----COOKIE-ACK > <-----HB-ACK+nonce (possibly bundled). Not possibly. IF the right side supports bundling it can send COOKIE-ACK,HB-ACK and the path is verified. If the right side does not support bundling the COOKIE-ACK is sent back and the HB-ACK is dropped (due to the new text ...) > B-Verified... > > > Similarly the receiver of an INIT can speed up verfication as > follows: > > INIT(IP-A, IP-B)----> > <-----to:IP-A-INIT-ACK() > ----COOKE-ECHO-----> > A Verified > <--to:IPB-COOKIE,ACK+HB/nonce > ----HB-ACK/nonce----> > B Verified Correct. > > This means one could quickly get two addresses verified... and > then any remaining addresses could be verified by the > HB-Verification procedure (or the HB/Nonce+DATA as they > fail over)... Correct. > > Hopefully sometime today I can get the words crafted for this > and send it to the list for wordsmitthing ;-D I think it is important - to make clear what the goal of the path verification is. - to require the basic principle shown above (before my first comment) - allow optimizations, like Brian is bundling a DATA chunk with the HB(nonce), or your proposed bundling of the HB(nonce) with COOKIE-ECHO or COOKIE-ACK. They are all optimizations, and there might be more... > One thing I am thinking is that there should be some wording > on packet conservation in this... i.e. any control type input packet > that is a request that drives a response must not generate > more than one output packet... > > R > > Brian F. G. Bidulock wrote: >> Michael, >> On Thu, 29 Sep 2005, Michael Tuexen wrote: >>>> Yes, and that's a good reason for limiting sending DATA with the >>>> verification HB to 1 packet (i.e. all the DATA you can bundle with >>>> the >>>> verification HB). But not a good reason not to send the DATA at >>>> all. >>> >>> One problem is if you send HB,DATA you expect a packet HB-ACK,SACK. >>> This response consists of two chunks. >>> If the receiver of the DATA does not support bundling, he would send >>> back HB-ACK and drop the SACK. This could require a retransmission >>> of the DATA... >> I don't know why the reecived would drop the SACK, but even if it >> does, >> the protocol handles SACKs that are dropped by the network. >> If the peer is going to drop SACKs then it cannot really complain >> about >> the resulting poor performance can it? >>>> You (or the security guys) say that bundling DATA with the HB will >>>> somehow expose it to an unverified address; however, it is to where >>>> the >>>> sender of the INIT requested that it be exposed whether it is >>>> verified >>>> or not. Please provide an example of how this can be a problem on >>>> the >>>> basis of "data exposure". >>> >>> I thought about this and think now, that there is no additional risk. >>> If you get the HB(nonce),DATA packet and can reply, you can also send >>> a HB-ACK(nonce). After that the path is verified and you can get >>> DATA. >>> >>> So I'm not against this bundling (anymore), but think that the >>> path verification is necessary. >> Good. I was only looking to have the leeway to send 1 packet of DATA >> bundled with the verification HB. I was certainly not wanting to >> require >> others to do it. >> I think that Randall also agreed that this can be permitted. >> --brian > > > -- > Randall Stewart > 803-345-0369 815-342-5222(cell) > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sat Oct 01 20:09:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELrPz-0006Mm-3r; Sat, 01 Oct 2005 20:09:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELrPx-0006L4-DX for tsvwg@megatron.ietf.org; Sat, 01 Oct 2005 20:09:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26574 for ; Sat, 1 Oct 2005 20:09:21 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[V50za6SV8B8Co1kmVCF5kkvAkP1uQW+/]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELrY6-0003nR-98 for tsvwg@ietf.org; Sat, 01 Oct 2005 20:17:52 -0400 Received: from ns.pigworks.openss7.net (IDENT:mORO6TD9tU88+Uoyk3MxG7y6MwMn9zMU@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j9208fc28357; Sat, 1 Oct 2005 18:08:41 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j9208dv09614; Sat, 1 Oct 2005 18:08:39 -0600 Date: Sat, 1 Oct 2005 18:08:39 -0600 From: "Brian F. G. Bidulock" To: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051001180839.A9410@openss7.org> References: <20050927163118.B12632@openss7.org> <20050927234315.A16994@openss7.org> <91bb78e5eac14f6e9588078a2233551e@lurchi.franken.de> <20050928012527.A18411@openss7.org> <20050929164043.B7159@openss7.org> <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> 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: <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de>; from Michael.Tuexen@lurchi.franken.de on Sat, Oct 01, 2005 at 09:09:40PM +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 j9208fc28357 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Randall Stewart , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael, On Sat, 01 Oct 2005, Michael Tuexen wrote: > > > > At the end of the above, two paths are verified (IP-A and IP-B). Now > > if the above is not good enough (since the COOKIE-ACK could be > > forged by the server) one could do: > > ----COOKIE-ECHO,HB/nonce-to:IP-B-> > > <----COOKIE-ACK > > <-----HB-ACK+nonce (possibly bundled). > Not possibly. IF the right side supports bundling it can send > COOKIE-ACK,HB-ACK and the path is verified. > If the right side does not support bundling the COOKIE-ACK is sent > back and the HB-ACK is dropped (due to the new text ...) It is only if the COOKIE-ACK and HB-ACK are sent to an unverified address that they need to be dropped. Right? Both could be sent to the sender of the INIT (an address already verified by the COOKIE-ECHO) could they not? It is packet multiplication towards a victim that we are concerned about, right? Not packet multiplication towards a verified host? But even if the HB-ACK is not sent because the receiver foolishly does not bundle, it will eventually be retransmitted, the receiver will just not reap the benefits of early verification. > > > > Hopefully sometime today I can get the words crafted for this > > and send it to the list for wordsmitthing ;-D > I think it is important > - to make clear what the goal of the path verification is. > - to require the basic principle shown above (before my first comment) > - allow optimizations, like Brian is bundling a DATA chunk with the > HB(nonce), or your proposed bundling of the HB(nonce) with COOKIE-EC= HO > or COOKIE-ACK. They are all optimizations, and there might be more... Yes, I think that it makes sense to leave the door open to reasonable optimizations that do not compromise the principle. But I'm interested to know whether this mulitple packet response concept only applies to unverified addresses. --brian --=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 tsvwg-bounces@ietf.org Sat Oct 01 20:12:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELrSX-0000TX-JE; Sat, 01 Oct 2005 20:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELrSU-0000OV-Ja for tsvwg@megatron.ietf.org; Sat, 01 Oct 2005 20:12:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26696 for ; Sat, 1 Oct 2005 20:11:58 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[5dpwUdEIQNQoY2KbU3hg6qA52DssKcbU]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELrae-0003rp-M9 for tsvwg@ietf.org; Sat, 01 Oct 2005 20:20:29 -0400 Received: from ns.pigworks.openss7.net (IDENT:GLrmXJi6aqrO+sH6mMb3H0pUT+aEUppm@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j920Bxc28397; Sat, 1 Oct 2005 18:11:59 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j920Bxn09652; Sat, 1 Oct 2005 18:11:59 -0600 Date: Sat, 1 Oct 2005 18:11:59 -0600 From: "Brian F. G. Bidulock" To: Michael Tuexen Subject: Re: [Tsvwg] SCTP IG: Reception of bundled chunks Message-ID: <20051001181159.B9410@openss7.org> References: <20050927164910.E12632@openss7.org> <20050927235449.C16994@openss7.org> <045c9893b4e3790e7b5c111ad2194ab5@lurchi.franken.de> <433E69DF.8020204@stewart.chicago.il.us> <68d8485abfda95ae573a4c0956cbce6f@lurchi.franken.de> 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: <68d8485abfda95ae573a4c0956cbce6f@lurchi.franken.de>; from Michael.Tuexen@lurchi.franken.de on Sat, Oct 01, 2005 at 08:57:52PM +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 j920Bxc28397 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: Randall Stewart , "'tsvwg@ietf.org'" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael, Same question as on the other thread: does this need to apply to verified addresses? Or only unverified addresses. Consider that many DATA chunks can ultimately be sent in response to a single DATA chunk (by the application). --brian On Sat, 01 Oct 2005, Michael Tuexen wrote: > Randy, >=20 > some minor changes: >=20 > When a packet containing multiple control or DATA chunks > is received and the processing of the packet > requires the sending of multiple chunks in > response, the sender of the response chunk('s) MUST NOT send > more than one packet. If bundling is supported > multiple response chunks that fit into a single packet MAY > be bundled together into one single response packet. If bundling > is not supported then the sender MUST NOT send more than one response > chunk and MUST discard all other responses. Note that this > rule does NOT apply to a SACK chunk since a SACK chunk > is, in itself, a response to DATA and a SACK does not > require a response of more DATA. >=20 > And then a question: What is the intention of the last sentence? >=20 > What is allowed to send back when you receive HB,UNKOWN,DATA,DATA[param= =20 > error]? > If the receiver supports bundling, it can send back a packet containing > HB-ACK, ERROR, SACK, ERROR if it fits. I would assume that only a HB-AC= K > is sent back, when the receiver of the packet does not support bundling= ? >=20 > Best regards > Michael >=20 --=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 tsvwg-bounces@ietf.org Sun Oct 02 07:35:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM27t-0006Qr-JR; Sun, 02 Oct 2005 07:35:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM27s-0006QX-Nb for tsvwg@megatron.ietf.org; Sun, 02 Oct 2005 07:35:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09719 for ; Sun, 2 Oct 2005 07:35:27 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EM2G8-0006BZ-0j for tsvwg@ietf.org; Sun, 02 Oct 2005 07:44:01 -0400 Received: from [192.168.1.10] (p5481E3DF.dip.t-dialin.net [84.129.227.223]) by ilsa.franken.de (Postfix) with ESMTP id CEF25245CB; Sun, 2 Oct 2005 13:35:03 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <20051001181159.B9410@openss7.org> References: <20050927164910.E12632@openss7.org> <20050927235449.C16994@openss7.org> <045c9893b4e3790e7b5c111ad2194ab5@lurchi.franken.de> <433E69DF.8020204@stewart.chicago.il.us> <68d8485abfda95ae573a4c0956cbce6f@lurchi.franken.de> <20051001181159.B9410@openss7.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0aa3f0c1e7562e5221e671900b161828@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Tsvwg] SCTP IG: Reception of bundled chunks Date: Sun, 2 Oct 2005 13:34:12 +0200 To: bidulock@openss7.org X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: Randall Stewart , "'tsvwg@ietf.org'" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi Brian, see my comments in-line. Best regards Michael On Oct 2, 2005, at 2:11 Uhr, Brian F. G. Bidulock wrote: > Michael, > > Same question as on the other thread: does this need to apply > to verified addresses? Or only unverified addresses. Soo my other mail. > > Consider that many DATA chunks can ultimately be sent in response > to a single DATA chunk (by the application). When I say 'response' I'm looking at the SCTP layer only. So a DATA chunk is never sent (in this sense) in response to a DATA chunk (it might be on the upper layer, for example an ASPUP-ACK in response to an ASPUP, but that is at a different layer). When I mean response, I mean a HB-ACK in response to an HB, an ERROR in response to an unknown chunk or a chunk with some kind of error, an INIT-ACK in response to an INIT, a COOKIE-ECHO in response to an INIT-ACK, a COOKIE-ACK in response to an COOKIE-ECHO, and so on... I also mean an ERROR in response to an INIT-ACK containing unknown parameters... I hope this makes this point clearer. Best regards Michael > > --brian > > On Sat, 01 Oct 2005, Michael Tuexen wrote: > >> Randy, >> >> some minor changes: >> >> When a packet containing multiple control or DATA chunks >> is received and the processing of the packet >> requires the sending of multiple chunks in >> response, the sender of the response chunk('s) MUST NOT send >> more than one packet. If bundling is supported >> multiple response chunks that fit into a single packet MAY >> be bundled together into one single response packet. If bundling >> is not supported then the sender MUST NOT send more than one response >> chunk and MUST discard all other responses. Note that this >> rule does NOT apply to a SACK chunk since a SACK chunk >> is, in itself, a response to DATA and a SACK does not >> require a response of more DATA. >> >> And then a question: What is the intention of the last sentence? >> >> What is allowed to send back when you receive=20 >> HB,UNKOWN,DATA,DATA[param >> error]? >> If the receiver supports bundling, it can send back a packet=20 >> containing >> HB-ACK, ERROR, SACK, ERROR if it fits. I would assume that only a=20 >> HB-ACK >> is sent back, when the receiver of the packet does not support=20 >> bundling? >> >> Best regards >> Michael >> > > --=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 tsvwg-bounces@ietf.org Sun Oct 02 08:24:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM2te-0002nN-EO; Sun, 02 Oct 2005 08:24:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM2tY-0002nI-Gc for tsvwg@megatron.ietf.org; Sun, 02 Oct 2005 08:24:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12139 for ; Sun, 2 Oct 2005 08:24:43 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EM31p-0007df-9P for tsvwg@ietf.org; Sun, 02 Oct 2005 08:33:17 -0400 Received: from [192.168.1.10] (p5481E3DF.dip.t-dialin.net [84.129.227.223]) by ilsa.franken.de (Postfix) with ESMTP id 0F295245C3; Sun, 2 Oct 2005 14:24:40 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <20051001180839.A9410@openss7.org> References: <20050927163118.B12632@openss7.org> <20050927234315.A16994@openss7.org> <91bb78e5eac14f6e9588078a2233551e@lurchi.franken.de> <20050928012527.A18411@openss7.org> <20050929164043.B7159@openss7.org> <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Sun, 2 Oct 2005 14:23:53 +0200 To: bidulock@openss7.org X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Randall Stewart , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hallo Brian, see my comments in-line. Best regards Michael On Oct 2, 2005, at 2:08 Uhr, Brian F. G. Bidulock wrote: > Michael, > > On Sat, 01 Oct 2005, Michael Tuexen wrote: > >>> >>> At the end of the above, two paths are verified (IP-A and IP-B). Now >>> if the above is not good enough (since the COOKIE-ACK could be >>> forged by the server) one could do: >>> ----COOKIE-ECHO,HB/nonce-to:IP-B-> >>> <----COOKIE-ACK >>> <-----HB-ACK+nonce (possibly bundled). >> Not possibly. IF the right side supports bundling it can send >> COOKIE-ACK,HB-ACK and the path is verified. >> If the right side does not support bundling the COOKIE-ACK is sent >> back and the HB-ACK is dropped (due to the new text ...) > > It is only if the COOKIE-ACK and HB-ACK are sent to an unverified > address that they need to be dropped. Right? Both could be sent > to the sender of the INIT (an address already verified by the > COOKIE-ECHO) could they not? It is packet multiplication towards > a victim that we are concerned about, right? Not packet = multiplication > towards a verified host? That is a very good point! I think that it is bad so send N packets in response to 1 packet in=20 general. But you are right, for the attacks being discussed it is important that an endpoint MUST NOT send multiple packets in response to one on unverified paths and MUST do the dropping. I'm not sure about the verified paths. Since the sending of the control chunks is not limited, one side can send a packet and the other side replies with 350 or so. This is bad for the network, I think. So I would prefer to use the same rule on verified paths and unverified paths. In my understanding the verification is mainly for sending DATA chunks because you will send multiple of them on reception of SACKs due to CC (I do not consider a DATA chunk a response to a SACK chunk). The control chunks should follow the 'one packet in, at most one out' rule. I definitely do not want to encourage people to reply with 350 packets to one packet (even if that path is verified). But you raised a very good point. Randy, others, what do you think? > But even if the HB-ACK is not sent because the receiver foolishly > does not bundle, it will eventually be retransmitted, the receiver > will just not reap the benefits of early verification. > >>> >>> Hopefully sometime today I can get the words crafted for this >>> and send it to the list for wordsmitthing ;-D >> I think it is important >> - to make clear what the goal of the path verification is. >> - to require the basic principle shown above (before my first = comment) >> - allow optimizations, like Brian is bundling a DATA chunk with the >> HB(nonce), or your proposed bundling of the HB(nonce) with=20 >> COOKIE-ECHO >> or COOKIE-ACK. They are all optimizations, and there might be=20 >> more... > > Yes, I think that it makes sense to leave the door open to reasonable > optimizations that do not compromise the principle. > > But I'm interested to know whether this mulitple packet response=20 > concept > only applies to unverified addresses. > > --brian > > --=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 tsvwg-bounces@ietf.org Sun Oct 02 08:32:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM30a-0005ZS-0N; Sun, 02 Oct 2005 08:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM30Y-0005ZN-L3 for tsvwg@megatron.ietf.org; Sun, 02 Oct 2005 08:31:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12369 for ; Sun, 2 Oct 2005 08:31:57 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EM38o-0007mR-Ez for tsvwg@ietf.org; Sun, 02 Oct 2005 08:40:31 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j92CVjEV014153; Sun, 2 Oct 2005 08:31:45 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <433FD331.7050402@stewart.chicago.il.us> Date: Sun, 02 Oct 2005 08:31:45 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Tsvwg] ICMP issue with SCTP IG References: <20050926111501.B27273@openss7.org> <20050927163526.D12632@openss7.org> <20050927234627.B16994@openss7.org> <61bc9bec27220ddbb93d36da04074962@lurchi.franken.de> <20050928014829.B18411@openss7.org> <433A9778.6080704@stewart.chicago.il.us> <20050928110748.D23449@openss7.org> <433E659A.9070906@stewart.chicago.il.us> <20051001052900.B3698@openss7.org> In-Reply-To: <20051001052900.B3698@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Brian F. G. Bidulock wrote: > Randall, > > I suppose it is not all that much more difficult. > > I think that most servers worried about this throttle to > a portion of the outoing bandwidth anyway. But IMO it is > not something that the application should protect against > but is the obligation of the transport. > > I would be interested in joining the draft if someone can > pass its name along. I will dig back through my email collection this next week and see if I can't provide you a pointer to the draft and the author R > > --brian > > On Sat, 01 Oct 2005, Randall Stewart wrote: > > >>Brian F. G. Bidulock wrote: >> >>>Randall, >>> >>>Segment number does not monotonically increase. >> >>But that makes no difference in this case.. since as you >>stated.. if I remember this thread right ... the >>"attacker" will be able to know enough about the >>app its getting to send data so it can 'predict' >>what the segments are going to be ... in TSN's. >>This is the same for TCP then.. instead of perdicting >>X bytes per TSN.. it changes the scaling.. thats all. >> >>So you end up with the same attack. >> >>I think that if you are really that concerned about this >>type of attack (I am not) then you need to join SCTP >>into the TCP document that illustrated the same attack >>and work with those authors to see if you can get >>adjustments made to both TCP and SCTP .. since they >>both have the same problem.. >> >>I will see if I can't go dig around in my >>other email account and find the draft name so then >>you can get in touch with those authors... >> >>R >> > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sun Oct 02 08:42:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM3B3-0001gm-Pk; Sun, 02 Oct 2005 08:42:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM3Ay-0001e5-IU for tsvwg@megatron.ietf.org; Sun, 02 Oct 2005 08:42:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12671 for ; Sun, 2 Oct 2005 08:42:43 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EM3JF-000806-9m for tsvwg@ietf.org; Sun, 02 Oct 2005 08:51:17 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j92CgfEV014176; Sun, 2 Oct 2005 08:42:41 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <433FD5C1.9070007@stewart.chicago.il.us> Date: Sun, 02 Oct 2005 08:42:41 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG References: <20050927163118.B12632@openss7.org> <20050927234315.A16994@openss7.org> <91bb78e5eac14f6e9588078a2233551e@lurchi.franken.de> <20050928012527.A18411@openss7.org> <20050929164043.B7159@openss7.org> <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> In-Reply-To: <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by stewart.chicago.il.us id j92CgfEV014176 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: quoted-printable Cc: bidulock@openss7.org, tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael/Brian: I was thinking that you applied this rule to verified and un-verified chunks.. And to answer Michaels other question about the last sentence.. (in his updated version which i like)... The point of the note about SACK is that a SACK is not something that sollicites a response. We do NOT want someone to interpret the rule so that they say.. -----DATA---> -----DATA---> <----SACK----- (a sack is soliciting a response for more data so only one data chunk may be sent) ---DATA----> The above would be bad... and is NOT meant by this rule... since a SACK, itself, IS a response but it does NOT ask for DATA to be sent... it ALLOWs data to be sent.. but this is differernt than HB----> <---HB-ACK or unknown chk----> <----ERROR The point of the last sentence is to prevent a niave implementation from doing the wrong thing with SACKs and DATA.. not that they would.. But you want something to make sure no one does an over-strict interpretation R Michael Tuexen wrote: > Hallo Brian, >=20 > see my comments in-line. >=20 > Best regards > Michael >=20 > On Oct 2, 2005, at 2:08 Uhr, Brian F. G. Bidulock wrote: >=20 >> Michael, >> >> On Sat, 01 Oct 2005, Michael Tuexen wrote: >> >>>> >>>> At the end of the above, two paths are verified (IP-A and IP-B). Now >>>> if the above is not good enough (since the COOKIE-ACK could be >>>> forged by the server) one could do: >>>> ----COOKIE-ECHO,HB/nonce-to:IP-B-> >>>> <----COOKIE-ACK >>>> <-----HB-ACK+nonce (possibly bundled). >>> >>> Not possibly. IF the right side supports bundling it can send >>> COOKIE-ACK,HB-ACK and the path is verified. >>> If the right side does not support bundling the COOKIE-ACK is sent >>> back and the HB-ACK is dropped (due to the new text ...) >> >> >> It is only if the COOKIE-ACK and HB-ACK are sent to an unverified >> address that they need to be dropped. Right? Both could be sent >> to the sender of the INIT (an address already verified by the >> COOKIE-ECHO) could they not? It is packet multiplication towards >> a victim that we are concerned about, right? Not packet multiplicatio= n >> towards a verified host? >=20 > That is a very good point! > I think that it is bad so send N packets in response to 1 packet in=20 > general. > But you are right, for the attacks being discussed it is important > that an endpoint MUST NOT send multiple packets in response to one > on unverified paths and MUST do the dropping. >=20 > I'm not sure about the verified paths. Since the sending of the control > chunks is not limited, one side can send a packet and the other side > replies with 350 or so. This is bad for the network, I think. >=20 > So I would prefer to use the same rule on verified paths and unverified > paths. In my understanding the verification is mainly for sending DATA > chunks because you will send multiple of them on reception of SACKs > due to CC (I do not consider a DATA chunk a response to a SACK chunk). > The control chunks should follow the 'one packet in, at most one out' > rule. >=20 > I definitely do not want to encourage people to reply with 350 packets > to one packet (even if that path is verified). >=20 > But you raised a very good point. Randy, others, what do you think? >=20 >> But even if the HB-ACK is not sent because the receiver foolishly >> does not bundle, it will eventually be retransmitted, the receiver >> will just not reap the benefits of early verification. >> >>>> >>>> Hopefully sometime today I can get the words crafted for this >>>> and send it to the list for wordsmitthing ;-D >>> >>> I think it is important >>> - to make clear what the goal of the path verification is. >>> - to require the basic principle shown above (before my first comment= ) >>> - allow optimizations, like Brian is bundling a DATA chunk with the >>> HB(nonce), or your proposed bundling of the HB(nonce) with=20 >>> COOKIE-ECHO >>> or COOKIE-ACK. They are all optimizations, and there might be more= ... >> >> >> Yes, I think that it makes sense to leave the door open to reasonable >> optimizations that do not compromise the principle. >> >> But I'm interested to know whether this mulitple packet response conce= pt >> only applies to unverified addresses. >> >> --brian >> >> --=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 >> >=20 >=20 >=20 >=20 --=20 Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sun Oct 02 08:56:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM3Ok-0007To-50; Sun, 02 Oct 2005 08:56:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM3Od-0007Tj-AX for tsvwg@megatron.ietf.org; Sun, 02 Oct 2005 08:56:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13179 for ; Sun, 2 Oct 2005 08:56:50 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EM3Wt-0008Lk-4M for tsvwg@ietf.org; Sun, 02 Oct 2005 09:05:24 -0400 Received: from [192.168.1.10] (p5481E3DF.dip.t-dialin.net [84.129.227.223]) by ilsa.franken.de (Postfix) with ESMTP id 13A97245C3; Sun, 2 Oct 2005 14:56:46 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <433FD5C1.9070007@stewart.chicago.il.us> References: <20050927163118.B12632@openss7.org> <20050927234315.A16994@openss7.org> <91bb78e5eac14f6e9588078a2233551e@lurchi.franken.de> <20050928012527.A18411@openss7.org> <20050929164043.B7159@openss7.org> <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Sun, 2 Oct 2005 14:56:00 +0200 To: Randall Stewart X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable Cc: bidulock@openss7.org, tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi Randy, see my comments in-line. Best regards Michael On Oct 2, 2005, at 14:42 Uhr, Randall Stewart wrote: > Michael/Brian: > > I was thinking that you applied this rule > to verified and un-verified chunks.. OK. I think this is the way to go. > > And to answer Michaels other question about > the last sentence.. (in his updated version > which i like)... > > The point of the note about SACK is that > a SACK is not something that sollicites a response. > We do NOT want someone to interpret the rule so that > they say.. > > -----DATA---> > -----DATA---> > <----SACK----- > (a sack is soliciting a response > for more data so only one data > chunk may be sent) > > ---DATA----> > > The above would be bad... and is NOT meant by > this rule... since a SACK, itself, IS a response > but it does NOT ask for DATA to be sent... it ALLOWs > data to be sent.. but this is differernt than > HB----> > <---HB-ACK > > or > > unknown chk----> > <----ERROR > > The point of the last sentence is to prevent a niave implementation > from doing the wrong thing with SACKs and DATA.. not that they would.. > But you want something to make sure no one does an over-strict > interpretation So this is what I stated in one of the last mails: I do not consider DATA chunks as a response to SACK chunks. Maybe we should write such a sentence and also give some examples like - a HB-ACK is a response to HB - INIT-ACK is a response to INIT - COOKIE-ECHO is a response to INIT-ACK - COOKIE-ACK is a response to COOKIE-ECHO - SACK is a response to DATA - SHUTDOWN-COMPLETE is a response to SHUTDOWN-ACK - SHUTDOWN-ACK is a response to SHUTDOWN - ERROR is a response to unknown chunks, unknown parameters in INIT-ACK, chunks with invalid fields, ... - ... but DATA is NOT a response to SACK. > > R > > > Michael Tuexen wrote: >> Hallo Brian, >> see my comments in-line. >> Best regards >> Michael >> On Oct 2, 2005, at 2:08 Uhr, Brian F. G. Bidulock wrote: >>> Michael, >>> >>> On Sat, 01 Oct 2005, Michael Tuexen wrote: >>> >>>>> >>>>> At the end of the above, two paths are verified (IP-A and IP-B).=20= >>>>> Now >>>>> if the above is not good enough (since the COOKIE-ACK could be >>>>> forged by the server) one could do: >>>>> ----COOKIE-ECHO,HB/nonce-to:IP-B-> >>>>> <----COOKIE-ACK >>>>> <-----HB-ACK+nonce (possibly bundled). >>>> >>>> Not possibly. IF the right side supports bundling it can send >>>> COOKIE-ACK,HB-ACK and the path is verified. >>>> If the right side does not support bundling the COOKIE-ACK is sent >>>> back and the HB-ACK is dropped (due to the new text ...) >>> >>> >>> It is only if the COOKIE-ACK and HB-ACK are sent to an unverified >>> address that they need to be dropped. Right? Both could be sent >>> to the sender of the INIT (an address already verified by the >>> COOKIE-ECHO) could they not? It is packet multiplication towards >>> a victim that we are concerned about, right? Not packet=20 >>> multiplication >>> towards a verified host? >> That is a very good point! >> I think that it is bad so send N packets in response to 1 packet in=20= >> general. >> But you are right, for the attacks being discussed it is important >> that an endpoint MUST NOT send multiple packets in response to one >> on unverified paths and MUST do the dropping. >> I'm not sure about the verified paths. Since the sending of the=20 >> control >> chunks is not limited, one side can send a packet and the other side >> replies with 350 or so. This is bad for the network, I think. >> So I would prefer to use the same rule on verified paths and=20 >> unverified >> paths. In my understanding the verification is mainly for sending = DATA >> chunks because you will send multiple of them on reception of SACKs >> due to CC (I do not consider a DATA chunk a response to a SACK = chunk). >> The control chunks should follow the 'one packet in, at most one out' >> rule. >> I definitely do not want to encourage people to reply with 350 = packets >> to one packet (even if that path is verified). >> But you raised a very good point. Randy, others, what do you think? >>> But even if the HB-ACK is not sent because the receiver foolishly >>> does not bundle, it will eventually be retransmitted, the receiver >>> will just not reap the benefits of early verification. >>> >>>>> >>>>> Hopefully sometime today I can get the words crafted for this >>>>> and send it to the list for wordsmitthing ;-D >>>> >>>> I think it is important >>>> - to make clear what the goal of the path verification is. >>>> - to require the basic principle shown above (before my first=20 >>>> comment) >>>> - allow optimizations, like Brian is bundling a DATA chunk with the >>>> HB(nonce), or your proposed bundling of the HB(nonce) with=20 >>>> COOKIE-ECHO >>>> or COOKIE-ACK. They are all optimizations, and there might be=20 >>>> more... >>> >>> >>> Yes, I think that it makes sense to leave the door open to = reasonable >>> optimizations that do not compromise the principle. >>> >>> But I'm interested to know whether this mulitple packet response=20 >>> concept >>> only applies to unverified addresses. >>> >>> --brian >>> >>> --=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 >>> > > > --=20 > Randall Stewart > 803-345-0369 815-342-5222(cell) > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sun Oct 02 21:26:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMF6L-0001iV-Kv; Sun, 02 Oct 2005 21:26:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMF6J-0001g2-4B for tsvwg@megatron.ietf.org; Sun, 02 Oct 2005 21:26:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12679 for ; Sun, 2 Oct 2005 21:26:41 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[1lTL1xKlTFt7/ja09ibTaZZSQegWzuYH]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMFEe-0007WB-8V for tsvwg@ietf.org; Sun, 02 Oct 2005 21:35:23 -0400 Received: from ns.pigworks.openss7.net (IDENT:fdzL6LbU+StD6yY97zIKrx7a5ahm5imc@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j931Pcc22127; Sun, 2 Oct 2005 19:25:38 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j931PYt02789; Sun, 2 Oct 2005 19:25:34 -0600 Date: Sun, 2 Oct 2005 19:25:34 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051002192534.A2754@openss7.org> References: <20050927163526.D12632@openss7.org> <20050927234627.B16994@openss7.org> <61bc9bec27220ddbb93d36da04074962@lurchi.franken.de> <20050928014829.B18411@openss7.org> <433A9778.6080704@stewart.chicago.il.us> <20050928110748.D23449@openss7.org> <433E659A.9070906@stewart.chicago.il.us> <20051001052900.B3698@openss7.org> <433FD331.7050402@stewart.chicago.il.us> 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: <433FD331.7050402@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Sun, Oct 02, 2005 at 08:31:45AM -0400 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 j931Pcc22127 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randall, Thanks. --brian On Sun, 02 Oct 2005, Randall Stewart wrote: > Brian F. G. Bidulock wrote: > > Randall, > >=20 > > I suppose it is not all that much more difficult. > >=20 > > I think that most servers worried about this throttle to > > a portion of the outoing bandwidth anyway. But IMO it is > > not something that the application should protect against > > but is the obligation of the transport. > >=20 > > I would be interested in joining the draft if someone can > > pass its name along. >=20 > I will dig back through my email collection this next week > and see if I can't provide you a pointer to the > draft and the author >=20 > R >=20 --=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 tsvwg-bounces@ietf.org Sun Oct 02 21:44:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMFNl-0000ZG-1F; Sun, 02 Oct 2005 21:44:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMFNj-0000YK-DD for tsvwg@megatron.ietf.org; Sun, 02 Oct 2005 21:44:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13071 for ; Sun, 2 Oct 2005 21:44:41 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[irL/ttLTTEmsciZ4k99GnaYf/sO20CEQ]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMFW6-0007nP-LP for tsvwg@ietf.org; Sun, 02 Oct 2005 21:53:23 -0400 Received: from ns.pigworks.openss7.net (IDENT:SnuOi+eD47Lx4S96TiOSUKs3qhVS2weu@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j931iEc22377; Sun, 2 Oct 2005 19:44:14 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j931iD802897; Sun, 2 Oct 2005 19:44:13 -0600 Date: Sun, 2 Oct 2005 19:44:13 -0600 From: "Brian F. G. Bidulock" To: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051002194413.B2754@openss7.org> References: <91bb78e5eac14f6e9588078a2233551e@lurchi.franken.de> <20050928012527.A18411@openss7.org> <20050929164043.B7159@openss7.org> <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> 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: <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de>; from Michael.Tuexen@lurchi.franken.de on Sun, Oct 02, 2005 at 02:56:00PM +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 j931iEc22377 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Randall Stewart , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael, But in effect they are. All these attacks are related. For unverified addresses we are allowing only 1 HB[nonce] packet with bundled DATA and other chunks, limiting packet amplification to 1. For verified addresses= , Max.Burst (yet to be explained) supposedly limits amplification to 4 (provided that there is no SACK spoofing, in which case the amplification could be as large as your ERROR chunk example). But limiting number of packets is not sufficient. I can send 1 packet with only enough unknown chunks necessary for you to bundle a full MTU in response, and I can still cause you to saturate your outgoing interface and deny service to all other users of the interface. In all the other examples, if you respond with a full MTU in response to my sending a much smaller packet, the amplifiction necessary for a DoS attack remains. Perhaps it is necessary to bring other chunks under congestion control, (i.e., apply cwnd rules to them, but not rwnd rules) and throttle them on a size (bandwidth) basis rather than a packet count basis. Otherwise the rule will probably need to state that the response packet can be no larger than the packet that solicited the response, which is of course not possible for the unknown error reporting chunks considered. --brian On Sun, 02 Oct 2005, Michael Tuexen wrote: > > > > The point of the last sentence is to prevent a niave implementation > > from doing the wrong thing with SACKs and DATA.. not that they would.. > > But you want something to make sure no one does an over-strict > > interpretation > So this is what I stated in one of the last mails: > I do not consider DATA chunks as a response to SACK chunks. > Maybe we should write such a sentence and also give some examples > like > - a HB-ACK is a response to HB > - INIT-ACK is a response to INIT > - COOKIE-ECHO is a response to INIT-ACK > - COOKIE-ACK is a response to COOKIE-ECHO > - SACK is a response to DATA > - SHUTDOWN-COMPLETE is a response to SHUTDOWN-ACK > - SHUTDOWN-ACK is a response to SHUTDOWN > - ERROR is a response to unknown chunks, unknown parameters in INIT-ACK= , > chunks with invalid fields, ... > - ... > but DATA is NOT a response to SACK. >=20 --=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 tsvwg-bounces@ietf.org Mon Oct 03 04:42:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMLtq-00067i-1Q; Mon, 03 Oct 2005 04:42:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMLto-00067d-A4 for tsvwg@megatron.ietf.org; Mon, 03 Oct 2005 04:42:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12464 for ; Mon, 3 Oct 2005 04:42:14 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMM2F-0008Li-QK for tsvwg@ietf.org; Mon, 03 Oct 2005 04:51:00 -0400 Received: from [192.168.1.10] (p5481F869.dip.t-dialin.net [84.129.248.105]) by ilsa.franken.de (Postfix) with ESMTP id 4EA36245C5; Mon, 3 Oct 2005 10:41:54 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <20051002194413.B2754@openss7.org> References: <91bb78e5eac14f6e9588078a2233551e@lurchi.franken.de> <20050928012527.A18411@openss7.org> <20050929164043.B7159@openss7.org> <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Mon, 3 Oct 2005 10:41:07 +0200 To: bidulock@openss7.org X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Randall Stewart , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Brian, see my comments in-line. Best regards Michael On Oct 3, 2005, at 3:44 Uhr, Brian F. G. Bidulock wrote: > Michael, > > But in effect they are. All these attacks are related. For = unverified > addresses we are allowing only 1 HB[nonce] packet with bundled DATA = and > other chunks, limiting packet amplification to 1. For verified=20 > addresses, > Max.Burst (yet to be explained) supposedly limits amplification to 4 > (provided that there is no SACK spoofing, in which case the=20 > amplification > could be as large as your ERROR chunk example). That is right and I do not think (at least I did not want) to say anything against it. > > But limiting number of packets is not sufficient. I can send 1 packet > with only enough unknown chunks necessary for you to bundle a full MTU > in response, and I can still cause you to saturate your outgoing > interface and deny service to all other users of the interface. In = all > the other examples, if you respond with a full MTU in response to my > sending a much smaller packet, the amplifiction necessary for a DoS > attack remains. Currently I'm looking a the ratio of number of packets to define the amplification factor, not the ratio of number of bytes. I think we agree that using the rules discussed before we have no amplification based on the ratio of number of packets. Looking at the response pairs, it is only the ERROR chunk returned to an unknown chunk which can be larger. It is, if it includes the unknown chunk. Maybe we should make this a MAY. So you can decide if you want to put the unknown chunk in (which helps=20 understanding what is going on) or to leave it out (which avoid longer responses). > > Perhaps it is necessary to bring other chunks under congestion = control, > (i.e., apply cwnd rules to them, but not rwnd rules) and throttle them > on a size (bandwidth) basis rather than a packet count basis. I do not think we need this. > > Otherwise the rule will probably need to state that the response = packet > can be no larger than the packet that solicited the response, which is > of course not possible for the unknown error reporting chunks=20 > considered. I think the rules we have right now are enough with the addition of the=20= above MAY and making the consequence clear. > > --brian > > On Sun, 02 Oct 2005, Michael Tuexen wrote: > >>> >>> The point of the last sentence is to prevent a niave implementation >>> from doing the wrong thing with SACKs and DATA.. not that they=20 >>> would.. >>> But you want something to make sure no one does an over-strict >>> interpretation >> So this is what I stated in one of the last mails: >> I do not consider DATA chunks as a response to SACK chunks. >> Maybe we should write such a sentence and also give some examples >> like >> - a HB-ACK is a response to HB >> - INIT-ACK is a response to INIT >> - COOKIE-ECHO is a response to INIT-ACK >> - COOKIE-ACK is a response to COOKIE-ECHO >> - SACK is a response to DATA >> - SHUTDOWN-COMPLETE is a response to SHUTDOWN-ACK >> - SHUTDOWN-ACK is a response to SHUTDOWN >> - ERROR is a response to unknown chunks, unknown parameters in=20 >> INIT-ACK, >> chunks with invalid fields, ... >> - ... >> but DATA is NOT a response to SACK. >> > > --=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 tsvwg-bounces@ietf.org Mon Oct 03 05:22:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMMWU-0002bi-Mq; Mon, 03 Oct 2005 05:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMMWR-0002aA-3r for tsvwg@megatron.ietf.org; Mon, 03 Oct 2005 05:22:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15058 for ; Mon, 3 Oct 2005 05:22:09 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[2ASWNnnDzy1I3Qla0c78OWrK+MezJM5/]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMMep-00013F-Dy for tsvwg@ietf.org; Mon, 03 Oct 2005 05:30:55 -0400 Received: from ns.pigworks.openss7.net (IDENT:6f3eqAESself3fupcmCgU8VqNlwAQzg7@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j939Lec31441; Mon, 3 Oct 2005 03:21:40 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j939Ldo08784; Mon, 3 Oct 2005 03:21:39 -0600 Date: Mon, 3 Oct 2005 03:21:39 -0600 From: "Brian F. G. Bidulock" To: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051003032139.A8423@openss7.org> References: <20050929164043.B7159@openss7.org> <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> 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: ; from Michael.Tuexen@lurchi.franken.de on Mon, Oct 03, 2005 at 10:41:07AM +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 j939Lec31441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Randall Stewart , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael, Please see below... On Mon, 03 Oct 2005, Michael Tuexen wrote: > Brian, >=20 > see my comments in-line. >=20 > Best regards > Michael >=20 > On Oct 3, 2005, at 3:44 Uhr, Brian F. G. Bidulock wrote: >=20 > > Michael, > > > > But in effect they are. All these attacks are related. For unverifi= ed > > addresses we are allowing only 1 HB[nonce] packet with bundled DATA a= nd > > other chunks, limiting packet amplification to 1. For verified=20 > > addresses, > > Max.Burst (yet to be explained) supposedly limits amplification to 4 > > (provided that there is no SACK spoofing, in which case the=20 > > amplification > > could be as large as your ERROR chunk example). > That is right and I do not think (at least I did not want) to say > anything against it. > > > > But limiting number of packets is not sufficient. I can send 1 packe= t > > with only enough unknown chunks necessary for you to bundle a full MT= U > > in response, and I can still cause you to saturate your outgoing > > interface and deny service to all other users of the interface. In a= ll > > the other examples, if you respond with a full MTU in response to my > > sending a much smaller packet, the amplifiction necessary for a DoS > > attack remains. > Currently I'm looking a the ratio of number of packets to define > the amplification factor, not the ratio of number of bytes. > I think we agree that using the rules discussed before we have no > amplification based on the ratio of number of packets. > Looking at the response pairs, it is only the ERROR chunk returned > to an unknown chunk which can be larger. It is, if it includes > the unknown chunk. Maybe we should make this a MAY. So you can > decide if you want to put the unknown chunk in (which helps=20 > understanding > what is going on) or to leave it out (which avoid longer responses). Not just ERROR. INIT-ACK can be much larger than INIT. Gosh, that's a simple attack, just send little INTIs with spoofed source address and let the big cookie laiden INIT-ACK go to the victim (or swamp the outgoing interface again). Perhaps we need to make the sender of the INIT pad the INIT out to match the size of the INIT-ACK. SACK can be much larger than DATA. Send many 1-byte DATA with many artifical TSN gaps, then send steady stream of same TSN 1-byte data spoofed from victim's unverified address. Rule says to send SACKs to where the data came from, and must be sent on each data packet when there are gaps or duplications. Boom! Or use attacker's verified address and overload the server's outgoing interface. Looks like one can't send any response packet to an unverified address not bundled with a HB[nonce]. Also, it looks like the rule about sending a response back to where it came from needs to be modified. Do we refuse to SACK data that is smaller than the resulting SACK? Even to verified addresses? SHUTDOWN is also a response to DATA. (And if no bundling, cannot report gaps or duplicates.) (With SACK can be much larger than DATA.) Same as SACK above. The only difference between bundling up a big response and sending many responses is the SCTP header, IP header and L2 header overhead, which is no so great. Although it is true that recievers in the past were frame rate limited, now they are bit rate limited. Bit amplification is worse than frame amplification. Sending 3 packets 1/4 the size is not as bad as sending 1 full sized packet. I don't think that it is enough to say that you have no amplification because you are sending packets 1 for 1. That might be true enough for TCP where the control information is contained in a few bits in the header. SCTP control chunks on the other hand have to be considered for size. For verified addresses, since the user is permitted to send multiple (DATA) packets in response to a single (DATA) packet, why cannot the protocol send multiple packets to verified addresses in response? --brian > > > > Perhaps it is necessary to bring other chunks under congestion contro= l, > > (i.e., apply cwnd rules to them, but not rwnd rules) and throttle the= m > > on a size (bandwidth) basis rather than a packet count basis. > I do not think we need this. > > > > Otherwise the rule will probably need to state that the response pack= et > > can be no larger than the packet that solicited the response, which i= s > > of course not possible for the unknown error reporting chunks=20 > > considered. > I think the rules we have right now are enough with the addition of the= =20 > above > MAY and making the consequence clear. > > > > --brian > > > > On Sun, 02 Oct 2005, Michael Tuexen wrote: > > > >>> > >>> The point of the last sentence is to prevent a niave implementation > >>> from doing the wrong thing with SACKs and DATA.. not that they=20 > >>> would.. > >>> But you want something to make sure no one does an over-strict > >>> interpretation > >> So this is what I stated in one of the last mails: > >> I do not consider DATA chunks as a response to SACK chunks. > >> Maybe we should write such a sentence and also give some examples > >> like > >> - a HB-ACK is a response to HB > >> - INIT-ACK is a response to INIT > >> - COOKIE-ECHO is a response to INIT-ACK > >> - COOKIE-ACK is a response to COOKIE-ECHO > >> - SACK is a response to DATA > >> - SHUTDOWN-COMPLETE is a response to SHUTDOWN-ACK > >> - SHUTDOWN-ACK is a response to SHUTDOWN > >> - ERROR is a response to unknown chunks, unknown parameters in=20 > >> INIT-ACK, > >> chunks with invalid fields, ... > >> - ... > >> but DATA is NOT a response to SACK. > >> > > > > --=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 > > --=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 tsvwg-bounces@ietf.org Mon Oct 03 13:53:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMUUv-0000xT-3G; Mon, 03 Oct 2005 13:53:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMUUt-0000xJ-Ri for tsvwg@megatron.ietf.org; Mon, 03 Oct 2005 13:53:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21189 for ; Mon, 3 Oct 2005 13:53:06 -0400 (EDT) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMUdP-0007Tn-4p for tsvwg@ietf.org; Mon, 03 Oct 2005 14:01:56 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id j93Hr4CX070357; Mon, 3 Oct 2005 10:53:04 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200510031753.j93Hr4CX070357@cougar.icir.org> To: Allison Mankin , jon.peterson@neustar.biz From: Sally Floyd Date: Mon, 03 Oct 2005 10:53:04 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "K.K. Ramakrishnan" , tsvwg@ietf.org, Aleksandar Kuzmanovic Subject: [Tsvwg] Adding ECN Capability to TCP's SYN/ACK packets X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Allison and Jon - Aleksandar, KK, and I have just submitted an internet-draft on "Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets", available from "http://www.icir.org/floyd/papers/draft-kuzmanovic-ecn-syn-00.txt". This is motivated by the SIGCOMM 2005 paper by Aleksandar on "The Power of Explicit Congestion Notification". Any feedback would be appreciated. If possible, I would like to talk about this briefly at TSVWG in Vancouver, and see if there is agreement for this to become an official tsvwg document. This is a pretty straightforward draft, and our hope is that it could go to Proposed Standard fairly soon. Many thanks, - Sally Abstract: This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specified setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document is specifying the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to an ECN mark by reducing its initial congestion window from two, three, or four segments to one segment, reducing the subsequent load from that connection on the network. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 03 14:46:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVKA-0001Pm-HK; Mon, 03 Oct 2005 14:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVK9-0001Ph-2u for tsvwg@megatron.ietf.org; Mon, 03 Oct 2005 14:46:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24203 for ; Mon, 3 Oct 2005 14:46:03 -0400 (EDT) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMVSd-0000aq-M6 for tsvwg@ietf.org; Mon, 03 Oct 2005 14:54:54 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id j93IjxGb071403 for ; Mon, 3 Oct 2005 11:45:59 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200510031845.j93IjxGb071403@cougar.icir.org> To: tsvwg@ietf.org From: Sally Floyd Subject: Re: [Tsvwg] Adding ECN Capability to TCP's SYN/ACK packets Date: Mon, 03 Oct 2005 11:45:59 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org >"http://www.icir.org/floyd/papers/draft-kuzmanovic-ecn-syn-00.txt". Sorry, the old copy only had the first two pages. My fault. It should all be there now. - Sally http://www.icir.org/floyd/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 03 15:20:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVqy-0006Dr-Cp; Mon, 03 Oct 2005 15:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVqu-0006Dg-Bm for tsvwg@megatron.ietf.org; Mon, 03 Oct 2005 15:19:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26521 for ; Mon, 3 Oct 2005 15:19:54 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMVzR-0001N9-2s for tsvwg@ietf.org; Mon, 03 Oct 2005 15:28:45 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j93JJbEV020703; Mon, 3 Oct 2005 15:19:43 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <43418448.7050003@stewart.chicago.il.us> Date: Mon, 03 Oct 2005 15:19:36 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Tsvwg] ICMP issue with SCTP IG References: <20050929164043.B7159@openss7.org> <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> <20051003032139.A8423@openss7.org> In-Reply-To: <20051003032139.A8423@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by stewart.chicago.il.us id j93JJbEV020703 X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Brian F. G. Bidulock wrote: >=20 > Not just ERROR. >=20 > INIT-ACK can be much larger than INIT. >=20 > Gosh, that's a simple attack, just send little INTIs with spoofed > source address and let the big cookie laiden INIT-ACK go to the > victim (or swamp the outgoing interface again). >=20 > Perhaps we need to make the sender of the INIT pad the INIT out > to match the size of the INIT-ACK. >=20 How can an INIT-ACK swamp an outgoing interface? You get one packet in.. and one packet out.. so what if the out bound packet is bigger.. I would be more worried that the Hashing algorithm is going to be more of a problem in ... and a 1:for:1 in/out is NOT an attack IMO... > SACK can be much larger than DATA. >=20 > Send many 1-byte DATA with many artifical TSN gaps, then send > steady stream of same TSN 1-byte data spoofed from victim's > unverified address. Rule says to send SACKs to where the data > came from, and must be sent on each data packet when there are > gaps or duplications. Boom! Or use attacker's verified address > and overload the server's outgoing interface. But again.. you are in a one packet to one packet scenario... I just can't see this has an amplification attack... sorry.. And you have similar issues (maybe not as big) with TCP-SACK... if you are worried about byte counts (which I am not in this case)... >=20 > Looks like one can't send any response packet to an unverified > address not bundled with a HB[nonce]. Also, it looks like the > rule about sending a response back to where it came from needs > to be modified. >=20 > Do we refuse to SACK data that is smaller than the resulting SACK? > Even to verified addresses? No, I think this is unneded... just like I don't think modifications to the where responses go is un-needed.... I can see where a cautious implemntation may well NOT send any response to a un-verified address.. but I don't see anything you have laid out as an amplification attack... >=20 > SHUTDOWN is also a response to DATA. (And if no bundling, cannot > report gaps or duplicates.) (With SACK can be much larger than DATA= .) >=20 > Same as SACK above. Again its a 1-for-1... and the only exception in the rule we talked about is a DATA in response to a SACK.. so in my mind SHUTDOWN in response to a DATA packet... WOULD hit the same new rule we are discussing.. aka only one response packet.. so you either bundle a SHUTDOWN+SACK or you send just a SHUTDOWN... >=20 > The only difference between bundling up a big response and sending > many responses is the SCTP header, IP header and L2 header overhead, > which is no so great. Although it is true that recievers in the past > were frame rate limited, now they are bit rate limited. Bit > amplification is worse than frame amplification. Sending 3 packets > 1/4 the size is not as bad as sending 1 full sized packet. I think I disagree with you here... and more so if you take this same microscope you are using you can find the same issues with TCP... A packet requires an interupt and often a context switch.. these IMO are far more heavy than if I have 100 bytes or 1000 bytes. >=20 > I don't think that it is enough to say that you have no amplification > because you are sending packets 1 for 1. That might be true enough > for TCP where the control information is contained in a few bits in the > header. SCTP control chunks on the other hand have to be considered > for size. >=20 > For verified addresses, since the user is permitted to send multiple > (DATA) packets in response to a single (DATA) packet, why cannot the > protocol send multiple packets to verified addresses in response? I don't see its needed... R >=20 > --brian >=20 >=20 >=20 >>>Perhaps it is necessary to bring other chunks under congestion control= , >>>(i.e., apply cwnd rules to them, but not rwnd rules) and throttle them >>>on a size (bandwidth) basis rather than a packet count basis. >> >>I do not think we need this. >> >>>Otherwise the rule will probably need to state that the response packe= t >>>can be no larger than the packet that solicited the response, which is >>>of course not possible for the unknown error reporting chunks=20 >>>considered. >> >>I think the rules we have right now are enough with the addition of the= =20 >>above >>MAY and making the consequence clear. >> >>>--brian >>> >>>On Sun, 02 Oct 2005, Michael Tuexen wrote: >>> >>> >>>>>The point of the last sentence is to prevent a niave implementation >>>>>from doing the wrong thing with SACKs and DATA.. not that they=20 >>>>>would.. >>>>>But you want something to make sure no one does an over-strict >>>>> interpretation >>>> >>>>So this is what I stated in one of the last mails: >>>>I do not consider DATA chunks as a response to SACK chunks. >>>>Maybe we should write such a sentence and also give some examples >>>>like >>>>- a HB-ACK is a response to HB >>>>- INIT-ACK is a response to INIT >>>>- COOKIE-ECHO is a response to INIT-ACK >>>>- COOKIE-ACK is a response to COOKIE-ECHO >>>>- SACK is a response to DATA >>>>- SHUTDOWN-COMPLETE is a response to SHUTDOWN-ACK >>>>- SHUTDOWN-ACK is a response to SHUTDOWN >>>>- ERROR is a response to unknown chunks, unknown parameters in=20 >>>>INIT-ACK, >>>> chunks with invalid fields, ... >>>>- ... >>>>but DATA is NOT a response to SACK. >>>> >>> >>>--=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 >>> >=20 >=20 --=20 Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 03 16:30:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWwl-0005RV-Q6; Mon, 03 Oct 2005 16:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWwk-0005Qa-Er for tsvwg@megatron.ietf.org; Mon, 03 Oct 2005 16:30:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10965 for ; Mon, 3 Oct 2005 16:29:59 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMX5F-00078R-TF for tsvwg@ietf.org; Mon, 03 Oct 2005 16:38:50 -0400 Received: from [192.168.1.10] (p5481CD82.dip.t-dialin.net [84.129.205.130]) by ilsa.franken.de (Postfix) with ESMTP id 115DE245D5; Mon, 3 Oct 2005 22:29:56 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <20051003032139.A8423@openss7.org> References: <20050929164043.B7159@openss7.org> <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> <20051003032139.A8423@openss7.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Mon, 3 Oct 2005 22:29:08 +0200 To: bidulock@openss7.org X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Randall Stewart , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Brian, see my comments in-line. Best regards Michael On Oct 3, 2005, at 11:21 Uhr, Brian F. G. Bidulock wrote: > Michael, > > Please see below... > > On Mon, 03 Oct 2005, Michael Tuexen wrote: > >> Brian, >> >> see my comments in-line. >> >> Best regards >> Michael >> >> On Oct 3, 2005, at 3:44 Uhr, Brian F. G. Bidulock wrote: >> >>> Michael, >>> >>> But in effect they are. All these attacks are related. For=20 >>> unverified >>> addresses we are allowing only 1 HB[nonce] packet with bundled DATA=20= >>> and >>> other chunks, limiting packet amplification to 1. For verified >>> addresses, >>> Max.Burst (yet to be explained) supposedly limits amplification to 4 >>> (provided that there is no SACK spoofing, in which case the >>> amplification >>> could be as large as your ERROR chunk example). >> That is right and I do not think (at least I did not want) to say >> anything against it. >>> >>> But limiting number of packets is not sufficient. I can send 1=20 >>> packet >>> with only enough unknown chunks necessary for you to bundle a full=20= >>> MTU >>> in response, and I can still cause you to saturate your outgoing >>> interface and deny service to all other users of the interface. In=20= >>> all >>> the other examples, if you respond with a full MTU in response to my >>> sending a much smaller packet, the amplifiction necessary for a DoS >>> attack remains. >> Currently I'm looking a the ratio of number of packets to define >> the amplification factor, not the ratio of number of bytes. >> I think we agree that using the rules discussed before we have no >> amplification based on the ratio of number of packets. >> Looking at the response pairs, it is only the ERROR chunk returned >> to an unknown chunk which can be larger. It is, if it includes >> the unknown chunk. Maybe we should make this a MAY. So you can >> decide if you want to put the unknown chunk in (which helps >> understanding >> what is going on) or to leave it out (which avoid longer responses). > > Not just ERROR. > > INIT-ACK can be much larger than INIT. > > Gosh, that's a simple attack, just send little INTIs with spoofed > source address and let the big cookie laiden INIT-ACK go to the > victim (or swamp the outgoing interface again). > > Perhaps we need to make the sender of the INIT pad the INIT out > to match the size of the INIT-ACK. I do NOT think that we should discuss on the ration of bytes. I consider the ration of packets to be the correct way. BTW, I have no idea as a sender of the INIT how big the INIT-ACK I get=20= back is.... > > SACK can be much larger than DATA. > > Send many 1-byte DATA with many artifical TSN gaps, then send > steady stream of same TSN 1-byte data spoofed from victim's > unverified address. Rule says to send SACKs to where the data > came from, and must be sent on each data packet when there are > gaps or duplications. Boom! Or use attacker's verified address > and overload the server's outgoing interface. > > Looks like one can't send any response packet to an unverified > address not bundled with a HB[nonce]. Also, it looks like the > rule about sending a response back to where it came from needs > to be modified. Why? You send the response to the source address of the request. > > Do we refuse to SACK data that is smaller than the resulting = SACK? > Even to verified addresses? No. We only say that you only send out one SACK even if it is too small to hold all gaps. > > SHUTDOWN is also a response to DATA. (And if no bundling, cannot > report gaps or duplicates.) (With SACK can be much larger than=20 > DATA.) > > Same as SACK above. I think the way to go is the look at the ratio of number of packets. And the procedures we discussed earlier handle this pretty well. > > The only difference between bundling up a big response and sending > many responses is the SCTP header, IP header and L2 header overhead, > which is no so great. Although it is true that recievers in the past > were frame rate limited, now they are bit rate limited. Bit > amplification is worse than frame amplification. Sending 3 packets > 1/4 the size is not as bad as sending 1 full sized packet. > > I don't think that it is enough to say that you have no amplification > because you are sending packets 1 for 1. That might be true enough > for TCP where the control information is contained in a few bits in = the > header. SCTP control chunks on the other hand have to be considered > for size. That is why we require in some extension IDs that only one 'request' is in flight. And why we had > > For verified addresses, since the user is permitted to send multiple > (DATA) packets in response to a single (DATA) packet, why cannot the > protocol send multiple packets to verified addresses in response? Because DATA chunks are subject to flow control and congestions control. Control chunks aren't. > > --brian > > >>> >>> Perhaps it is necessary to bring other chunks under congestion=20 >>> control, >>> (i.e., apply cwnd rules to them, but not rwnd rules) and throttle=20 >>> them >>> on a size (bandwidth) basis rather than a packet count basis. >> I do not think we need this. >>> >>> Otherwise the rule will probably need to state that the response=20 >>> packet >>> can be no larger than the packet that solicited the response, which=20= >>> is >>> of course not possible for the unknown error reporting chunks >>> considered. >> I think the rules we have right now are enough with the addition of=20= >> the >> above >> MAY and making the consequence clear. >>> >>> --brian >>> >>> On Sun, 02 Oct 2005, Michael Tuexen wrote: >>> >>>>> >>>>> The point of the last sentence is to prevent a niave = implementation >>>>> from doing the wrong thing with SACKs and DATA.. not that they >>>>> would.. >>>>> But you want something to make sure no one does an over-strict >>>>> interpretation >>>> So this is what I stated in one of the last mails: >>>> I do not consider DATA chunks as a response to SACK chunks. >>>> Maybe we should write such a sentence and also give some examples >>>> like >>>> - a HB-ACK is a response to HB >>>> - INIT-ACK is a response to INIT >>>> - COOKIE-ECHO is a response to INIT-ACK >>>> - COOKIE-ACK is a response to COOKIE-ECHO >>>> - SACK is a response to DATA >>>> - SHUTDOWN-COMPLETE is a response to SHUTDOWN-ACK >>>> - SHUTDOWN-ACK is a response to SHUTDOWN >>>> - ERROR is a response to unknown chunks, unknown parameters in >>>> INIT-ACK, >>>> chunks with invalid fields, ... >>>> - ... >>>> but DATA is NOT a response to SACK. >>>> >>> >>> --=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 >>> > > --=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 tsvwg-bounces@ietf.org Tue Oct 04 01:31:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMfOk-0001Mm-N1; Tue, 04 Oct 2005 01:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMfOg-0001Me-Fk for tsvwg@megatron.ietf.org; Tue, 04 Oct 2005 01:31:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14069 for ; Tue, 4 Oct 2005 01:31:25 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[OHmqMpzOlTYo/L5VayEuEvS5Klgo9HF6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMfXI-0005uP-Dt for tsvwg@ietf.org; Tue, 04 Oct 2005 01:40:21 -0400 Received: from ns.pigworks.openss7.net (IDENT:fNWBZKA2EjX5rCHOw6cs39LdbPer4Wl9@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j945Ubc18162; Mon, 3 Oct 2005 23:30:37 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j945UZ720103; Mon, 3 Oct 2005 23:30:35 -0600 Date: Mon, 3 Oct 2005 23:30:35 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051003233035.A19472@openss7.org> References: <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> <20051003032139.A8423@openss7.org> <43418448.7050003@stewart.chicago.il.us> 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: <43418448.7050003@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Mon, Oct 03, 2005 at 03:19:36PM -0400 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 j945Ubc18162 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randall, On Mon, 03 Oct 2005, Randall Stewart wrote: > Brian F. G. Bidulock wrote: >=20 > >=20 > > Not just ERROR. > >=20 > > INIT-ACK can be much larger than INIT. > >=20 > > Gosh, that's a simple attack, just send little INTIs with spoofe= d > > source address and let the big cookie laiden INIT-ACK go to the > > victim (or swamp the outgoing interface again). > >=20 > > Perhaps we need to make the sender of the INIT pad the INIT out > > to match the size of the INIT-ACK. > >=20 >=20 > How can an INIT-ACK swamp an outgoing interface? You get > one packet in.. and one packet out.. so what if the > out bound packet is bigger.. I would be more worried that > the Hashing algorithm is going to be more of a problem in > ... and a 1:for:1 in/out is NOT an attack IMO... Oh really? Give me two host IP addresses (one host with SCTP, the other doesn't matter) and permission (from the owner of the hosts) and I will demonstrate. Most INIT-ACKs are double the size on the wire as the INIT. With a bunch of continue/report unrecognized parameters added to the INIT, I can squeak that up to triple the size on the wire (while nicely keeping your hash computational load down lower). I send INITs as fast as I can to the first IP address, and the INIT-ACKs go to the second IP address (spoofed source address). I send, say 1Mbps (on the wire) to you and you send 3Mbps (on the wire) onwards to the other. For my 1Mbps I use up 1Mbps incoming and 3Mbps outgoing on the first host and use up 3Mbps incoming on the second host. The second host will discard the INIT-ACKs (at least the ones that it is capable of receiving). The first host will receive no indication that there is a problem if the second host is SCTP capable. So for my 1Mbps, I use up 4Mbps of the first host's interface and 3Mbps of the second host's and 4Mbps of the shared network. Sounds like amplification to me. No attack? All I need is a fraction of the bandwidth available to me as you have and I can pretty much guarantee that you (and the other host that upon inspection will think the attack is coming from the first host) will not be performing any useful transport across their interfaces. Also, if the first host is not too efficient on hash computation, I can probably even deny service to local processes. And for an indenfinite period of time. And that is only if the network is a football to us. If the network is a barbell, all I need is a fraction of the bandwidth of the bottleneck in the barbell and I can pretty much grind the network to a halt. Gosh you would have to use MPLS or something and put protocol 132 into a low-bandwidth sandbox just to stop me. Particularly if I take my (hypothetical) 50 compromized servers and put them to the task. What's worse, is if I take my 50 compromized servers and distribute my spoofed INITs across 5000 servers, focussing the INIT-ACKs on one victim, and the network is a football, the victim can say goodbye. And it will be very difficult to trace the origin of the attack. I don't want to give that opportunity to a bunch of disgruntled types, do you? You think that byte multiplication is acceptable? That only packet count multiplication counts? Michael? You think that too? Well, protect your servers. Now that I mentioned it publicly even a script kiddie could do it in minutes. If TCP SACK is the same way, think twice about deploying it. Plainjane TCP does not have to worry because the byte multiplication is just not there. PJ TCP can talk in terms of packet multiplication. SCTP is a completely different beast. I think that we had better consider byte amplification. --brian --=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 tsvwg-bounces@ietf.org Tue Oct 04 04:56:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMiba-0001Gz-Ft; Tue, 04 Oct 2005 04:56:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMibZ-0001Gl-Au for tsvwg@megatron.ietf.org; Tue, 04 Oct 2005 04:56:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05501 for ; Tue, 4 Oct 2005 04:56:55 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMikD-0002D2-Fp for tsvwg@ietf.org; Tue, 04 Oct 2005 05:05:53 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j948uO1h009342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 4 Oct 2005 09:56:24 +0100 (BST) Message-ID: <434243B7.1060703@erg.abdn.ac.uk> Date: Tue, 04 Oct 2005 09:56:23 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sally Floyd Subject: Re: [Tsvwg] Re: draft-ietf-tsvwg-quickstart-00: A new contruction of RR Nonce References: <200509291857.j8TIvj2r001940@cougar.icir.org> In-Reply-To: <200509291857.j8TIvj2r001940@cougar.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: pasi.sarolahti@iki.fi, tsvwg@ietf.org, lguohan , mallman@icir.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Thanks for writing this up - and IMHO, it make sense to consider this as an attractive alternative to more complex varients. I have no "feel" for the issues in using an 8 v. 4 byte nonce. Many of the issues in using an option field apply in both cases: space, PMTUD, etc; are there any specific impacts if we used 8 bytes? Regarding the proposal of "Use Format X for the Rate Request Field" - could this also have implications on this new-style nonce: Does allowing a range of rate formats, imply a range of nonce behaviours, if so - then I'm less happy with this as a "final" solution - because I'd still like to be fairly cautious on what I expect routers to do and I'd like to see some of this reach low-level support in standard routers. Gorry Sally Floyd wrote: > Guohan > > >>This email proposes a new way construct the RR Nonce which provides a >>different kind of protection as the current one. > > > Many thanks for the feedback. We have been thinking about alternatives > for the nonce over the last few weeks with Gorry Fairhurst, who > volunteered at the last IETF to give us feedback, and your email > has encouraged me to rethink my preference for keeping the QS option > at four bytes instead of eight. I now think that an eight-byte QS > option would be fine, with simplicity of the option valued over > space-efficiency. > > So here is the current version of the QS nonce that some of us > are thinking about, based in part on your email, and in part > on earlier suggestions from Gorry. Your feedback would be > welcome. > > One open issue is whether there is any reason to strongly prefer a > four-byte IP option over an eight-byte IP option. If anyone has > any feedback on this, that would be appreciated as well. > > Many thanks! > > - Sally > http://www.icir.org/tmrg/ > -------------------------------------------------------------------- > The modified Lu proposal (also proposed by Gorry): > > 0 1 2 3 > +--------------+--------------+--------------+--------------+ > | Option | Length=4 | QS TTL |Resv. |Rate | > | | | | |Request| > +--------------+--------------+--------------+--------------+ > | | QS Nonce | > | | | > +--------------+--------------+--------------+--------------+ > > QS Nonce: > Bits 0-1: Reserved > Bits 2-3: rate 15 -> rate 14 > Bits 4-5: rate 14 -> rate 13 > Bits 6-7: rate 13 -> rate 12 > Bits 8-9: rate 12 -> rate 11 > Bits 10-11: rate 11 -> rate 10 > Bits 12-13: rate 10 -> rate 9 > Bits 14-15: rate 9 -> rate 8 > Bits 16-17: rate 8 -> rate 7 > Bits 18-19: rate 7 -> rate 6 > Bits 20-21: rate 6 -> rate 5 > Bits 22-23: rate 5 -> rate 4 > Bits 24-25: rate 4 -> rate 3 > Bits 26-27: rate 3 -> rate 2 > Bits 28-29: rate 2 -> rate 1 > Bits 30-31: rate 1 -> rate 0 > > The sender initializes the 29-bit nonce to a random value. If the > router reduces the rate request from rate K to rate K-1, then the > router sets the two bits in the nonce for "rate K -> rate K-1" to > a new random value. (Almost any form of pseudo-randomness would > do - it doesn't need to be fancy.) So if the receiver reduces the > rate request by N steps, the receiver rewrites 2N bits in the nonce. > The receiver reports the nonce back to the sender. > > The receiver has a 1/4 chance of cleating about each step change > in the rate request. If the rate request was reduced by two or > more steps in the network, the receiver has at most a 1/16 chance > of reporting that the original request was approved. > > The protection is the same whether one router makes all of the > decrements in the rate request, or whether they are made at > different routers along the path. > > The reason for routers to enter new bits in the nonce rather than > setting those bits to zero is to make it harder for the > receiver to know the original rate request. If the receiver > doesn't know if the rate request was reduced in the network > or not, then it is harder for the receiver to cheat. > > There are six bits left as Reserved. > E.g., for new forms of rate request in the future. > > The only issue would be whether there is some reason to strongly > prefer a four-byte IP option over an eight-byte IP option. > > _______________________________________________ > 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 tsvwg-bounces@ietf.org Tue Oct 04 08:38:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMm3y-0006j7-Fe; Tue, 04 Oct 2005 08:38:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMm3w-0006iw-6O for tsvwg@megatron.ietf.org; Tue, 04 Oct 2005 08:38:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15251 for ; Tue, 4 Oct 2005 08:38:26 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMmCb-0007ek-EL for tsvwg@ietf.org; Tue, 04 Oct 2005 08:47:26 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j94CcBEV024174; Tue, 4 Oct 2005 08:38:16 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <434277B3.3070603@stewart.chicago.il.us> Date: Tue, 04 Oct 2005 08:38:11 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Tsvwg] ICMP issue with SCTP IG References: <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> <20051003032139.A8423@openss7.org> <43418448.7050003@stewart.chicago.il.us> <20051003233035.A19472@openss7.org> In-Reply-To: <20051003233035.A19472@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Brian F. G. Bidulock wrote: > SCTP is a completely different beast. I think that we had better > consider byte amplification. So far.. only you have spoken up on this.. Michael as said we should look in terms of packets.. I agree. Lets see if anyone else in the wg think this is an issue... Anyone else, besides Brian, on the list think we should worry about the number of bytes in vs the number of bytes out? R -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 04 09:30:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMmsP-0006po-DL; Tue, 04 Oct 2005 09:30:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMmsL-0006pf-Ir for tsvwg@megatron.ietf.org; Tue, 04 Oct 2005 09:30:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18970 for ; Tue, 4 Oct 2005 09:30:31 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMn10-0000zJ-Nq for tsvwg@ietf.org; Tue, 04 Oct 2005 09:39:32 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j94DUMEV024374; Tue, 4 Oct 2005 09:30:22 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <434283EE.2060606@stewart.chicago.il.us> Date: Tue, 04 Oct 2005 09:30:22 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Tsvwg] ICMP issue with SCTP IG References: <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> <20051003032139.A8423@openss7.org> <43418448.7050003@stewart.chicago.il.us> <20051003233035.A19472@openss7.org> In-Reply-To: <20051003233035.A19472@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Brian: Thinking about this some more... maybe we do need at least a couple of changes on the verification procedures: 1) Not allow ANYTHING but a HB+nonce to be sent to an unverified address. This would also include control. 2) NOT allow data to be bundled with a HB+nonce, as you wanted, since this would be a form of "byte amplification". 3) NOT EVEN the HB-ACK should be sent back to a non-verified address. That way you get it back, if you are a malicious attacker.. and this should be no problem since I think most implemenatations (if they have done any testing at all) will have been putting the destination they sent the HB to inside the HB... This handles ALL but the INIT/INIT-ACK case... and I do not think that you can address that easily... Michael's earlier change to say MAY report unrecognized parameters (if I remember his statements right) would help in this regard (by the way, in looking at 2960 I see no MUST that I have to send an uncrecognized parameter anyway). But you cannot get rid of the need to have a larger INIT-ACK just because you have the COOKIE inside it... this comes down to a classic security trade off.... do you protect against TCB exhaustion (aka the SYN attack) or do you protect against a 'byte amplification' type attack... In this case I think the SYN attack is far better to protect against... I still am not as concerned about "byte amplification" as you are, but making the above changes will minimize this to hopefully make you happy R -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 04 10:44:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMo1y-0004Q7-HE; Tue, 04 Oct 2005 10:44:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMo1w-0004Pv-ET for tsvwg@megatron.ietf.org; Tue, 04 Oct 2005 10:44:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24154 for ; Tue, 4 Oct 2005 10:44:30 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMoAX-0002zt-HF for tsvwg@ietf.org; Tue, 04 Oct 2005 10:53:32 -0400 Received: from [194.95.73.130] (unknown [194.95.73.130]) by ilsa.franken.de (Postfix) with ESMTP id C4EA924B0C; Tue, 4 Oct 2005 16:44:05 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <434283EE.2060606@stewart.chicago.il.us> References: <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> <20051003032139.A8423@openss7.org> <43418448.7050003@stewart.chicago.il.us> <20051003233035.A19472@openss7.org> <434283EE.2060606@stewart.chicago.il.us> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <251e1593e36b0d0e75a63d66fc42f823@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Tue, 4 Oct 2005 16:43:18 +0200 To: Randall Stewart X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: bidulock@openss7.org, tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randy, see my comments in-line. Best regards Michael On Oct 4, 2005, at 15:30 Uhr, Randall Stewart wrote: > Brian: > > Thinking about this some more... maybe we do > need at least a couple of changes on the verification > procedures: > > 1) Not allow ANYTHING but a HB+nonce to be sent to > an unverified address. This would also include control. > > 2) NOT allow data to be bundled with a HB+nonce, as you wanted, > since this would be a form of "byte amplification". These points mean: You MUST verify the path first using HB(nonce) and you MUST NOT send anything else. There is no distinction necessary between DATA and control chunks. > > 3) NOT EVEN the HB-ACK should be sent back to a non-verified address. > That way you get it back, if you are a malicious attacker.. and > this should be no problem since I think most implemenatations (if > they have done any testing at all) will have been putting the > destination they sent the HB to inside the HB... No. You will send a HB(nonce) to an unverified address and the HB-ACK might have to go back to an unverified address. And that is not problem, because size(HB-ACK) == size(HB). So we do not need a restriction here. > > This handles ALL but the INIT/INIT-ACK case... and I do not think > that you can address that easily... Michael's earlier change to say > MAY report unrecognized parameters (if I remember his statements right) > would help in this regard (by the way, in looking at 2960 I see > no MUST that I have to send an uncrecognized parameter anyway). But > you cannot get rid of the need to have a larger INIT-ACK just because > you have the COOKIE inside it... this comes down to a classic > security trade off.... do you protect against TCB exhaustion (aka > the SYN attack) or do you protect against a 'byte amplification' type > attack... In this case I think the SYN attack is far better to > protect against... > > I still am not as concerned about "byte amplification" as you are, but > making the above changes will minimize this to hopefully make you > happy I think the above procedure is pretty simple and I support it. However, we should still not encourage implementations to reply to one packet with more than 350 packets... So we should still have the text with the bundling... > > R > > -- > Randall Stewart > 803-345-0369 815-342-5222(cell) > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 04 12:28:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpeY-0008SP-Il; Tue, 04 Oct 2005 12:28:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpeW-0008Rv-Pw for tsvwg@megatron.ietf.org; Tue, 04 Oct 2005 12:28:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07768 for ; Tue, 4 Oct 2005 12:28:25 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMpnD-0000AW-PJ for tsvwg@ietf.org; Tue, 04 Oct 2005 12:37:29 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j94GSIEV024975; Tue, 4 Oct 2005 12:28:19 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <4342ADA2.2070500@stewart.chicago.il.us> Date: Tue, 04 Oct 2005 12:28:18 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG References: <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> <20051003032139.A8423@openss7.org> <43418448.7050003@stewart.chicago.il.us> <20051003233035.A19472@openss7.org> <434283EE.2060606@stewart.chicago.il.us> <251e1593e36b0d0e75a63d66fc42f823@lurchi.franken.de> In-Reply-To: <251e1593e36b0d0e75a63d66fc42f823@lurchi.franken.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: bidulock@openss7.org, tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael: See below... Michael Tuexen wrote: > Randy, > > see my comments in-line. > > Best regards > Michael > > On Oct 4, 2005, at 15:30 Uhr, Randall Stewart wrote: > >> Brian: >> >> Thinking about this some more... maybe we do >> need at least a couple of changes on the verification >> procedures: >> >> 1) Not allow ANYTHING but a HB+nonce to be sent to >> an unverified address. This would also include control. >> >> 2) NOT allow data to be bundled with a HB+nonce, as you wanted, >> since this would be a form of "byte amplification". > > These points mean: You MUST verify the path first using HB(nonce) > and you MUST NOT send anything else. There is no distinction > necessary between DATA and control chunks. > >> >> 3) NOT EVEN the HB-ACK should be sent back to a non-verified address. >> That way you get it back, if you are a malicious attacker.. and >> this should be no problem since I think most implemenatations (if >> they have done any testing at all) will have been putting the >> destination they sent the HB to inside the HB... > > No. You will send a HB(nonce) to an unverified address and the > HB-ACK might have to go back to an unverified address. And that > is not problem, because size(HB-ACK) == size(HB). So we do not > need a restriction here. Why? If you have a verified address, you should be able to send the HB-ACK back to that address without causing a problem.. It is being over-precautious... mind you.. but one could do this.. I don't mind if we don't :-D > >> >> This handles ALL but the INIT/INIT-ACK case... and I do not think >> that you can address that easily... Michael's earlier change to say >> MAY report unrecognized parameters (if I remember his statements right) >> would help in this regard (by the way, in looking at 2960 I see >> no MUST that I have to send an uncrecognized parameter anyway). But >> you cannot get rid of the need to have a larger INIT-ACK just because >> you have the COOKIE inside it... this comes down to a classic >> security trade off.... do you protect against TCB exhaustion (aka >> the SYN attack) or do you protect against a 'byte amplification' type >> attack... In this case I think the SYN attack is far better to >> protect against... >> >> I still am not as concerned about "byte amplification" as you are, but >> making the above changes will minimize this to hopefully make you >> happy > > I think the above procedure is pretty simple and I support it. However, > we should still not encourage implementations to reply to one packet > with more than 350 packets... So we should still have the text with > the bundling... Yep... I agree... the other thing is we COULD possibly craft some warnings about responding to a large INIT... (one that might be for amplification). If one thinks about it... you almost cannot get away from having the cookie be at least: a) The peers addresses, (say 2 IPv4's.. thats at least 8 bytes) b) The tags and sequence numbers (16 bytes) c) A timestamp.. (say 4 bytes) d) A signature (16 or 20 bytes) So no matter how big the INIT is .. the INIT-ACK will probably always add at a minimum of 40 extra bytes.... But there are other methods for dealing with this type of attack... aka: RPF checks, ingress screening, and rate limiting of INIT's.. come to mind.. I am sure there are others.. So I don't think it is that big of issue... maybe not even worth addressing in the I-G R -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 04 14:27:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMrVI-0007Vq-Ep; Tue, 04 Oct 2005 14:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMrVG-0007Vb-PJ for tsvwg@megatron.ietf.org; Tue, 04 Oct 2005 14:27:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15703 for ; Tue, 4 Oct 2005 14:27:01 -0400 (EDT) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMrdx-00043N-0t for tsvwg@ietf.org; Tue, 04 Oct 2005 14:36:04 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id j94IQaPi005379; Tue, 4 Oct 2005 11:26:36 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200510041826.j94IQaPi005379@cougar.icir.org> To: gorry@erg.abdn.ac.uk From: Sally Floyd Subject: Re: [Tsvwg] Re: draft-ietf-tsvwg-quickstart-00: A new contruction of RR Nonce Date: Tue, 04 Oct 2005 11:26:36 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: pasi.sarolahti@iki.fi, tsvwg@ietf.org, lguohan , mallman@icir.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org >Thanks for writing this up - and IMHO, it make sense to consider this as an >attractive alternative to more complex varients. Good. My inclination is to incorporate it into the proposal to be considered for Experimental, unless I hear any negative feedback. >I have no "feel" for the issues in using an 8 v. 4 byte nonce. Many of the >issues in using an option field apply in both cases: space, PMTUD, etc; are >there any specific impacts if we used 8 bytes? I don't know of any reasons to prefer a four-byte instead of an eight-byte IP option, expect for the generic one of not wasting bandwidth unnecessarily on headers in general. >Regarding the proposal of "Use Format X for the Rate Request Field" >- could this also have implications on this new-style nonce: Does allowing a >range of rate formats, imply a range of nonce behaviours, if so - then I'm >less happy with this as a "final" solution - because I'd still like to be >fairly cautious on what I expect routers to do and I'd like to see some of >this reach low-level support in standard routers. That wasn't a proposal. That was just a list of some of the things that have been mentioned at one time or another as possible uses for extra bits in the Quick-Start Option. It wouldn't have implications for the new-style nonce - the new-style nonce would work the same with any four-bit rate request field, regardless of the format for interpreting the requests in that field. I also don't expect there to be a need for other formats for the rate request field. The only reason I could think of would be if the maximum rate request of 1 Gbps wasn't big enough. But my hope would be that people playing around with larger initial sending rates than 1 Gbps are using something more powerful than Quick-Start - e.g., some form of QoS, or of per-flow state at routers, or end-to-end light paths, or something else... - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 04 15:40:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMseR-0006gU-AP; Tue, 04 Oct 2005 15:40:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMseP-0006gP-Qq for tsvwg@megatron.ietf.org; Tue, 04 Oct 2005 15:40:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20755 for ; Tue, 4 Oct 2005 15:40:31 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMsn9-0005yu-Du for tsvwg@ietf.org; Tue, 04 Oct 2005 15:49:36 -0400 Received: from [192.168.1.10] (p5481CD3F.dip.t-dialin.net [84.129.205.63]) by ilsa.franken.de (Postfix) with ESMTP id D43D6245DD; Tue, 4 Oct 2005 21:40:26 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <4342ADA2.2070500@stewart.chicago.il.us> References: <433D2D18.8090509@stewart.chicago.il.us> <05b6f2b1eb77fadb7de47aaa3f456312@lurchi.franken.de> <20051001180839.A9410@openss7.org> <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> <20051003032139.A8423@openss7.org> <43418448.7050003@stewart.chicago.il.us> <20051003233035.A19472@openss7.org> <434283EE.2060606@stewart.chicago.il.us> <251e1593e36b0d0e75a63d66fc42f823@lurchi.franken.de> <4342ADA2.2070500@stewart.chicago.il.us> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Tue, 4 Oct 2005 21:39:38 +0200 To: Randall Stewart X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Cc: bidulock@openss7.org, tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randy, see my comments in-line. Best regards Michael On Oct 4, 2005, at 18:28 Uhr, Randall Stewart wrote: > Michael: > > See below... > > Michael Tuexen wrote: >> Randy, >> see my comments in-line. >> Best regards >> Michael >> On Oct 4, 2005, at 15:30 Uhr, Randall Stewart wrote: >>> Brian: >>> >>> Thinking about this some more... maybe we do >>> need at least a couple of changes on the verification >>> procedures: >>> >>> 1) Not allow ANYTHING but a HB+nonce to be sent to >>> an unverified address. This would also include control. >>> >>> 2) NOT allow data to be bundled with a HB+nonce, as you wanted, >>> since this would be a form of "byte amplification". >> These points mean: You MUST verify the path first using HB(nonce) >> and you MUST NOT send anything else. There is no distinction >> necessary between DATA and control chunks. > >>> >>> 3) NOT EVEN the HB-ACK should be sent back to a non-verified address. >>> That way you get it back, if you are a malicious attacker.. and >>> this should be no problem since I think most implemenatations (if >>> they have done any testing at all) will have been putting the >>> destination they sent the HB to inside the HB... >> No. You will send a HB(nonce) to an unverified address and the >> HB-ACK might have to go back to an unverified address. And that >> is not problem, because size(HB-ACK) == size(HB). So we do not >> need a restriction here. > > Why? > > If you have a verified address, you should be able to send > the HB-ACK back to that address without causing a problem.. It > is being over-precautious... mind you.. but one could do this.. > I don't mind if we don't :-D I do not see a problem, because the HB-ACK is one packet exactly like the HB and it has the same length. So I do not see how this process can be misused. That is why I would like to have as much freedom as possible. > >>> >>> This handles ALL but the INIT/INIT-ACK case... and I do not think >>> that you can address that easily... Michael's earlier change to say >>> MAY report unrecognized parameters (if I remember his statements >>> right) >>> would help in this regard (by the way, in looking at 2960 I see >>> no MUST that I have to send an uncrecognized parameter anyway). But >>> you cannot get rid of the need to have a larger INIT-ACK just because >>> you have the COOKIE inside it... this comes down to a classic >>> security trade off.... do you protect against TCB exhaustion (aka >>> the SYN attack) or do you protect against a 'byte amplification' type >>> attack... In this case I think the SYN attack is far better to >>> protect against... >>> >>> I still am not as concerned about "byte amplification" as you are, >>> but >>> making the above changes will minimize this to hopefully make you >>> happy >> I think the above procedure is pretty simple and I support it. >> However, >> we should still not encourage implementations to reply to one packet >> with more than 350 packets... So we should still have the text with >> the bundling... > > Yep... I agree... the other thing is we COULD possibly craft > some warnings about responding to a large INIT... (one that > might be for amplification). Hmmm. The point is that is does not have to be a large INIT. If the server has N addresses the INIT-ACK will be of the size of the INIT + constant + constant * N. So a server with a lot of addresses will produce large INIT-ACKs even for small INITs. So one could use some heuristics to try to decide if a particular INIT is used for an attack. One could even use some sort of shaping... However, I think as you point out below, the INIT-ACK is larger than the INIT. The only way around that might be an additional padding parameter which make the INIT larger and is not put into the INIT-ACK. That could be used to get the size of the INIT larger as the size of the INIT-ACK. The receiver could, if the padding is too small, send an ERROR/ABORT indicating that the padding is too small. Like the COOKIE lifetime stuff. But currently I do not think that it is worth the effort. In summary: Using the path verification stuff with unbundled HB(nonce) there is no packet or byte amplification to victims which are not the SCTP endpoint except the INIT/INIT-ACK pair. There is no packet amplification, but the possibility of an byte amplification. A way around that would be an optional padding parameter, which makes the INIT larger. But I do not think that it is worth it at the moment. For verified paths we should enforce the 'one packet in, at most one packet out' rule for control chunks as pointed out (and agreed earlier). > > If one thinks about it... you almost cannot get away > from having the cookie be at least: > > a) The peers addresses, (say 2 IPv4's.. thats at > least 8 bytes) > b) The tags and sequence numbers (16 bytes) > c) A timestamp.. (say 4 bytes) > d) A signature (16 or 20 bytes) > > So no matter how big the INIT is .. the INIT-ACK will > probably always add at a minimum of 40 extra bytes.... > > But there are other methods for dealing with this type > of attack... > > aka: RPF checks, ingress screening, and rate limiting > of INIT's.. come to mind.. I am sure there are others.. > > So I don't think it is that big of issue... maybe not > even worth addressing in the I-G > > R > > > -- > Randall Stewart > 803-345-0369 815-342-5222(cell) > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Oct 05 04:48:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN4xM-0000HI-Al; Wed, 05 Oct 2005 04:48:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN4xJ-0000Gw-RD for tsvwg@megatron.ietf.org; Wed, 05 Oct 2005 04:48:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07140 for ; Wed, 5 Oct 2005 04:48:51 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[fD1gmBhFXeY+RE+yBL+8ouWNP4hQHVDH]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN569-0003zL-In for tsvwg@ietf.org; Wed, 05 Oct 2005 04:58:03 -0400 Received: from ns.pigworks.openss7.net (IDENT:QubWH3i25tnhQmnlKKm/eO7Ei1NyMCfL@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j958lxc14550; Wed, 5 Oct 2005 02:47:59 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j958lvD07605; Wed, 5 Oct 2005 02:47:57 -0600 Date: Wed, 5 Oct 2005 02:47:57 -0600 From: "Brian F. G. Bidulock" To: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051005024757.A7394@openss7.org> References: <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> <20051003032139.A8423@openss7.org> <43418448.7050003@stewart.chicago.il.us> <20051003233035.A19472@openss7.org> <434283EE.2060606@stewart.chicago.il.us> <251e1593e36b0d0e75a63d66fc42f823@lurchi.franken.de> 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: <251e1593e36b0d0e75a63d66fc42f823@lurchi.franken.de>; from Michael.Tuexen@lurchi.franken.de on Tue, Oct 04, 2005 at 04:43:18PM +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 j958lxc14550 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Randall Stewart , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael, On Tue, 04 Oct 2005, Michael Tuexen wrote: > > > > I still am not as concerned about "byte amplification" as you are, bu= t > > making the above changes will minimize this to hopefully make you > > happy > I think the above procedure is pretty simple and I support it. However, > we should still not encourage implementations to reply to one packet > with more than 350 packets... So we should still have the text with > the bundling... The way things stand, it makes little difference whether you send 350 ERROR chunks to me in 350 packets or in 1 packet. The most compute intensive task for bogus packets (for a non-HW assist SCTP aware host) is checksumming the payload of the packets, which is roughly the same in either case. The way that RFC 3309 is worded ("When an SCTP packet is received, the receiver MUST first check the CRC-32c checksum"), I am prohibited from checking for a bogus SCTP header until the checksum is calculated in full. So I must checksum every byte of every ERROR chunk regardless of whether there are 350 in one packet, or 350 in 350 packets. Note also that the attacker does not have this compute load. The attacker can use canned messages (precalculated checksum INIT messages that are simply sent over and over again). If RFC 3309 was worded differently the situation would be different on the compute side. If I was allowed to check the IP and SCTP headers to see if the packet is bogus (regardless of the validity of the checksum= ) and then only checksum when the header shows the packet to be possibly genuine, then all bogus INIT-ACK packets could be discarded in constant time regardless of size and 1 big packet would be better than 350 small packets from the compute side. (I do this already, but imps that follow RFC 3309 to the letter will not.) In terms of bandwidth consumption they are roughly the same, however. --brian --=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 tsvwg-bounces@ietf.org Wed Oct 05 04:53:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN51j-00023s-Hk; Wed, 05 Oct 2005 04:53:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN51i-00023m-2B for tsvwg@megatron.ietf.org; Wed, 05 Oct 2005 04:53:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07318 for ; Wed, 5 Oct 2005 04:53:23 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[TctcYcSxlgFVHBpdiCuBRxuFTLaSJ8yd]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN5AY-00047H-TX for tsvwg@ietf.org; Wed, 05 Oct 2005 05:02:35 -0400 Received: from ns.pigworks.openss7.net (IDENT:XLkEEOkva5MJkqH5cZ80djeCtI/ObdvT@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j958qpc14931; Wed, 5 Oct 2005 02:52:51 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j958qpp07674; Wed, 5 Oct 2005 02:52:51 -0600 Date: Wed, 5 Oct 2005 02:52:51 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051005025251.B7394@openss7.org> References: <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> <20051003032139.A8423@openss7.org> <43418448.7050003@stewart.chicago.il.us> <20051003233035.A19472@openss7.org> <434283EE.2060606@stewart.chicago.il.us> <251e1593e36b0d0e75a63d66fc42f823@lurchi.franken.de> <4342ADA2.2070500@stewart.chicago.il.us> 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: <4342ADA2.2070500@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Tue, Oct 04, 2005 at 12:28:18PM -0400 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 j958qpc14931 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randall, On Tue, 04 Oct 2005, Randall Stewart wrote: >=20 > But there are other methods for dealing with this type > of attack... >=20 > aka: RPF checks, ingress screening, and rate limiting > of INIT's.. come to mind.. I am sure there are others.. Rate limiting INITs will invite DoS attacks on the rate limit. All the attacker need do is exceed the rate and all other INITs are denied. This was learnt a long time ago with SYNs. I though we even had a recommendation against rate limiting of INITs. Also, because they are INITs you cannot rate limit on any basis that the attacker cannot spoof. --brian --=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 tsvwg-bounces@ietf.org Fri Oct 07 08:39:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrVF-0000Rv-4N; Fri, 07 Oct 2005 08:39:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrVE-0000Rq-1I for tsvwg@megatron.ietf.org; Fri, 07 Oct 2005 08:39:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15201 for ; Fri, 7 Oct 2005 08:39:06 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENreS-0004Gs-RR for tsvwg@ietf.org; Fri, 07 Oct 2005 08:48:44 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j97CchEV045959; Fri, 7 Oct 2005 08:38:50 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <43466C4B.4060303@stewart.chicago.il.us> Date: Fri, 07 Oct 2005 08:38:35 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org References: <18367e9e03951beba0046afd6ffecec4@lurchi.franken.de> <433FD5C1.9070007@stewart.chicago.il.us> <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> <20051003032139.A8423@openss7.org> <43418448.7050003@stewart.chicago.il.us> <20051003233035.A19472@openss7.org> <434283EE.2060606@stewart.chicago.il.us> <251e1593e36b0d0e75a63d66fc42f823@lurchi.franken.de> <20051005024757.A7394@openss7.org> In-Reply-To: <20051005024757.A7394@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner Subject: [Tsvwg] Bogus SCTP header X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Lets try to change the topic.. since this is NOT an ICMP issue... Brian F. G. Bidulock wrote: > Michael, > > On Tue, 04 Oct 2005, Michael Tuexen wrote: > > >>>I still am not as concerned about "byte amplification" as you are, but >>>making the above changes will minimize this to hopefully make you >>>happy >> >>I think the above procedure is pretty simple and I support it. However, >>we should still not encourage implementations to reply to one packet >>with more than 350 packets... So we should still have the text with >>the bundling... > > > The way things stand, it makes little difference whether you send 350 > ERROR chunks to me in 350 packets or in 1 packet. The most compute > intensive task for bogus packets (for a non-HW assist SCTP aware host) > is checksumming the payload of the packets, which is roughly the same > in either case. And what do you mean by a "bogus" packet? - One that does not belong to an association? - One that belongs to an association but contains a bunch of errors? The question really becomes "how much of the packet are you willing to look at and trust without knowning if the data is corrupted or not" This is the issue. On an attacker sense, an "evil attacker" can setup a valid association with you and then flood you with packets that have perfectly acceptable headers.. and yet are filled with error reports... and a bogus checksum... even if you check the header before you check the rest.. you would still end up doing the crc32c.. A change in 3309 (which is inside the I-G) would not help this. It COULD help the case where you have an invalid header.. and thus save checksuming the packet... but this is a minor annoyance as far as processing goes... you don't get that many errored packets.... But it won't help in an attacker case... the bigger issue was that we elected to go with CRC32C IMO.. I was against this, I am not proposing to change it, but it would have been better to do CRC32.. since then the ability to have hardware assist would have been MUCH MUCH better... sigh.. As far as going down the path of allowing you to root around in the SCTP packet BEFORE you do a checksum... I just don't see the value in this... since you have to look at much more than just 4 bytes (the ports)... and as I said, an attacker can setup a nice association with you and then flood you with errors that have perfectly valid headers and a bogus checksum... R > > The way that RFC 3309 is worded ("When an SCTP packet is received, > the receiver MUST first check the CRC-32c checksum"), I am prohibited > from checking for a bogus SCTP header until the checksum is calculated > in full. So I must checksum every byte of every ERROR chunk regardless > of whether there are 350 in one packet, or 350 in 350 packets. > > Note also that the attacker does not have this compute load. The > attacker can use canned messages (precalculated checksum INIT messages > that are simply sent over and over again). > > If RFC 3309 was worded differently the situation would be different > on the compute side. If I was allowed to check the IP and SCTP headers > to see if the packet is bogus (regardless of the validity of the checksum) > and then only checksum when the header shows the packet to be possibly > genuine, then all bogus INIT-ACK packets could be discarded in constant > time regardless of size and 1 big packet would be better than 350 small > packets from the compute side. (I do this already, but imps that follow > RFC 3309 to the letter will not.) > > In terms of bandwidth consumption they are roughly the same, however. > > --brian > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 07 13:45:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwHk-00023q-Tc; Fri, 07 Oct 2005 13:45:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwHh-00023h-Dv for tsvwg@megatron.ietf.org; Fri, 07 Oct 2005 13:45:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02360 for ; Fri, 7 Oct 2005 13:45:27 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[B0C3Pfqj3wkwG6vRqaHszNdWoFczi0VL]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENwQz-0000jN-0H for tsvwg@ietf.org; Fri, 07 Oct 2005 13:55:08 -0400 Received: from ns.pigworks.openss7.net (IDENT:ZkgDyMSbwLTRMlBVY7VSICyItfajqpwE@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j97Hifc11931; Fri, 7 Oct 2005 11:44:41 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j97HieH09301; Fri, 7 Oct 2005 11:44:40 -0600 Date: Fri, 7 Oct 2005 11:44:40 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Message-ID: <20051007114440.A9085@openss7.org> References: <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de> <20051002194413.B2754@openss7.org> <20051003032139.A8423@openss7.org> <43418448.7050003@stewart.chicago.il.us> <20051003233035.A19472@openss7.org> <434283EE.2060606@stewart.chicago.il.us> <251e1593e36b0d0e75a63d66fc42f823@lurchi.franken.de> <20051005024757.A7394@openss7.org> <43466C4B.4060303@stewart.chicago.il.us> 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: <43466C4B.4060303@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Fri, Oct 07, 2005 at 08:38:35AM -0400 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 j97Hifc11931 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner Subject: [Tsvwg] Re: Bogus SCTP header X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randall, Its not a big deal. I don't trust anything, I just change the order in which things are done. All I do now is check that the SCTP header has a correct length, that there exists a valid first chunk header, and use the SCTP header to see if an association exists. If one does not exist and the policy is not to send ABORT to OOTB packets (permitted by the I-G for port scanning), I discard without checksumming. Otherwise, I checksum before delivering it to the association. Thus if I am flooded with OOTB packets from any of the bombing attacks, I discard them without checksumming. For those attacks, byte amplification would have less meaning for processing power, but still meaning for bandwidth. Point being, MUST should be changed to SHOULD on the order of doing things. It does not endanger the network or destroy interoperability by changing the order of doing some things and the MUST in regard to order is unwarranted. Yes, in the attacks that do not include OOTB packets, this does not help much. So byte amplification is still important (because you have to checksum each and every byte), and packet amplification less important. --brian --=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 tsvwg-bounces@ietf.org Fri Oct 07 15:14:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENxgD-0002WO-PQ; Fri, 07 Oct 2005 15:14:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENxgB-0002WG-Eg for tsvwg@megatron.ietf.org; Fri, 07 Oct 2005 15:14:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07524 for ; Fri, 7 Oct 2005 15:14:49 -0400 (EDT) Received: from host52a.simplicato.com ([207.99.47.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENxpT-0004N6-RK for tsvwg@ietf.org; Fri, 07 Oct 2005 15:24:31 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 0C8E369AD2E; Fri, 7 Oct 2005 15:14:26 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63634-07-6; Fri, 7 Oct 2005 15:14:25 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 4944F69AD7E; Fri, 7 Oct 2005 15:14:19 -0400 (EDT) Received: from 63.87.1.243 (SquirrelMail authenticated user cait@asomi.com) by mail.host52a.simplicato.com with HTTP; Fri, 7 Oct 2005 12:14:19 -0700 (PDT) Message-ID: <21553.63.87.1.243.1128712459.squirrel@mail.host52a.simplicato.com> In-Reply-To: <20051007114440.A9085@openss7.org> References: <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de><20051002194413.B2754@openss7.org><20051003032139.A8423@openss7.org><43418448.7050003@stewart.chicago.il.us><20051003233035.A19472@openss7.org><434283EE.2060606@stewart.chicago.il.us><251e1593e36b0d0e75a63d66fc42f823@lurchi.franken.de><20051005024757.A7394@openss7.org><43466C4B.4060303@stewart.chicago.il.us> <20051007114440.A9085@openss7.org> Date: Fri, 7 Oct 2005 12:14:19 -0700 (PDT) Subject: Re: [Tsvwg] Re: Bogus SCTP header From: "Caitlin Bestler" To: bidulock@openss7.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, Michael Tuexen , Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Randall Stewart , Scott Bradner , Kacheong Poon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Brian F. G. Bidulock said: > Randall, > > Its not a big deal. I don't trust anything, I just change the > order in which things are done. All I do now is check that the > SCTP header has a correct length, that there exists a valid > first chunk header, and use the SCTP header to see if an > association exists. If one does not exist and the policy is not > to send ABORT to OOTB packets (permitted by the I-G for port > scanning), I discard without checksumming. Otherwise, I > checksum before delivering it to the association. > > Thus if I am flooded with OOTB packets from any of the bombing > attacks, I discard them without checksumming. For those > attacks, byte amplification would have less meaning for > processing power, but still meaning for bandwidth. > > Point being, MUST should be changed to SHOULD on the order of > doing things. It does not endanger the network or destroy > interoperability by changing the order of doing some things > and the MUST in regard to order is unwarranted. > I agree with Randall's point that saving checksum calculation on rare packets is not much of an optimization. But I don't see how it is relevant. If an SCTP implementation MUST NOT do X, and it does nothing that any external entity can detect that implies it did X, then why does it need the language downgraded to a SHOULD? -- Caitlin Bestler http://asomi.com/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 07 17:20:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENzdq-0002Hp-Fp; Fri, 07 Oct 2005 17:20:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENzdn-0002Hh-Mx for tsvwg@megatron.ietf.org; Fri, 07 Oct 2005 17:20:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25311 for ; Fri, 7 Oct 2005 17:20:28 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[ZydAA44gNdGhU4gAXOqp+yplrxlFaOgA]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENzn8-00050x-B9 for tsvwg@ietf.org; Fri, 07 Oct 2005 17:30:12 -0400 Received: from ns.pigworks.openss7.net (IDENT:pAEq7v/0i5dw17puH7kLr5jkkkuBKw1T@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j97LJac14839; Fri, 7 Oct 2005 15:19:36 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j97LJZN11089; Fri, 7 Oct 2005 15:19:35 -0600 Date: Fri, 7 Oct 2005 15:19:34 -0600 From: "Brian F. G. Bidulock" To: Caitlin Bestler Subject: Re: [Tsvwg] Re: Bogus SCTP header Message-ID: <20051007151934.A11057@openss7.org> References: <9281c2b3b401f70cac11cfe8a403bfb6@lurchi.franken.de><20051002194413.B2754@openss7.org><20051003032139.A8423@openss7.org><43418448.7050003@stewart.chicago.il.us><20051003233035.A19472@openss7.org><434283EE.2060606@stewart.chicago.il.us><251e1593e36b0d0e75a63d66fc42f823@lurchi.franken.de><20051005024757.A7394@openss7.org><43466C4B.4060303@stewart.chicago.il.us> <20051007114440.A9085@openss7.org> <21553.63.87.1.243.1128712459.squirrel@mail.host52a.simplicato.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: <21553.63.87.1.243.1128712459.squirrel@mail.host52a.simplicato.com>; from cait@asomi.com on Fri, Oct 07, 2005 at 12:14:19PM -0700 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 j97LJac14839 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, Michael Tuexen , Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Randall Stewart , Scott Bradner , Kacheong Poon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Caitlin, On Fri, 07 Oct 2005, Caitlin Bestler wrote: >=20 > I agree with Randall's point that saving checksum calculation > on rare packets is not much of an optimization. But I don't > see how it is relevant. >=20 > If an SCTP implementation MUST NOT do X, and it does nothing > that any external entity can detect that implies it did X, > then why does it need the language downgraded to a SHOULD? >=20 In fitting with the use of requirements keywords, it seems pointless to say MUST with regard to something that is not externally detectable. That is clearly requiring an implementation to do a thing a certain way that is not ncessary for interoperability or protection of the netwrok, a misuse of the keyword: somthing that the requirements language RFC discusses. When we say MUST, do we wnat to invite implementations to do differently, just as long as they can't get caught? I think we should use MUST only when we expect an implementation to do no different, whether detectable or not. That's why I say that the language should be changed to say that the checksum MUST be checked before responding to the packet and leave the order of checking other items concerning validity of the packet to the implementation. --brian --=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 tsvwg-bounces@ietf.org Tue Oct 11 16:00:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPQIn-00062N-Mj; Tue, 11 Oct 2005 16:00:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPQIl-0005yw-Ax for tsvwg@megatron.ietf.org; Tue, 11 Oct 2005 16:00:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27967 for ; Tue, 11 Oct 2005 16:00:40 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPQSr-0007QI-H9 for tsvwg@ietf.org; Tue, 11 Oct 2005 16:11:12 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j9BK0IEV073587; Tue, 11 Oct 2005 16:00:19 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <4346A997.5070300@stewart.chicago.il.us> Date: Fri, 07 Oct 2005 13:00:07 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG References: <260bfb19542b53463de0c3410fc4badc@lurchi.franken.de> <43305CE9.1000408@stewart.chicago.il.us> <20050921015053.A10788@openss7.org> <40738d159d9c90c6d69f7ee3e6210db1@lurchi.franken.de> <20050921111932.A26114@openss7.org> <20050921162304.A29088@openss7.org> <28d6f7b73746b7bbe5b706a75222ce50@lurchi.franken.de> <20050922045114.B6756@openss7.org> <69d50fe7d87f21c6298f1f561145c166@lurchi.franken.de> <20050923033810.B18747@openss7.org> <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> In-Reply-To: <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: 7bit Cc: bidulock@openss7.org, tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org All: In an attempt to draw this discussion and all the points we have discussed to a close here is the text I am proposing we add to the I-G. This I think covers all of our issues... Our new section 11.5 now looks as follows: ********************************************************* --------- New text --------- 11.5 Protection of non-SCTP capable hosts. To provide non-SCTP capable host with the same level of protection against attacks as SCTP capable ones all SCTP stacks MUST implement the ICMP handling described in Appendix C. When an SCTP stack receives a packet containing multiple control or DATA chunks and the processing of the packet requires the sending of multiple chunks in response, the sender of the response chunk('s) MUST NOT send more than one packet. If bundling is supported multiple response chunks that fit into a single packet MAY be bundled together into one single response packet. If bundling is not supported then the sender MUST NOT send more than one response chunk and MUST discard all other responses. Note that this rule does NOT apply to a SACK chunk since a SACK chunk is, in itself, a response to DATA and a SACK does not require a response of more DATA. An SCTP implementation SHOULD abort the association if it receives a SACK acknowledging a TSN which has not been sent. An SCTP implementation that receives an INIT that would require a large packet in response, due to the inclusion of multiple ERROR parameters, MAY (at its discrection) elect to omit some or all of the ERROR parameters to reduce the size of the INIT-ACK. Due to a combination of the size of the COOKIE parameter and the number of addresses a receiver of an INIT may be indicating to a peer, it is always possible that the INIT-ACK will be larger than the original INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as small as possible to reduce the possibility of byte amplification attacks. ************************************************************* The ICMP section that goes with it looks as follows: ************************************************************* --------- New text: (Appendix C) --------- Appendix C ICMP Handling Whenever an ICMP message is received by an SCTP endpoint the following procedures MUST be followed to assure proper utilization of the information being provided by layer 3. ICMP1) Ignore all ICMPv4 messages where the type field is not set to "Destination Unreachable". ICMP2) Ignore all ICMPv6 messages where the type field is not "Destination Unreachable, "Parameter Problem" or "Packet Too Big". ICMP3) Ignore any ICMPv4 messages where the code does not indicate "Protocol Unreachable" or "Fragmentation Needed". ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if the code is not "Unrecognized next header type encountered". ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the association which sent the message that ICMP is responding to. If the association cannot be found, ignore the ICMP message. ICMP6) Validate that the verification tag contained in the ICMP message matches the verification tag of the peer. If the verification tag is not 0 and does NOT match, discard the ICMP message. If it is 0 and the ICMP message contains enough bytes to verify that the chunk type is an INIT chunk and that the initiate tag matches the tag of the peer continue with ICMP7. If the ICMP message is too short, the chunk type or the initiate tag does not match, silently discard the packet. ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 "Fragmentation Needed" process this information as defined for PATH MTU discovery. ICMP8) If the ICMP code is a "Unrecognized next header type encountered" or a "Protocol Unreachable" treat this message as an abort with the T bit set if it does not contain an INIT chunk. If it does contain an INIT chunk and the association is in COOKIE-WAIT state, handle the ICMP message like an ABORT. ICMP9) If the ICMP code is an "Unrecognized next header type encountered" or a "Protocol Unreachable" then the message MUST be treated as an abort with the T bit set, checking the Verification Tag in the ICMP message for validation. ICMP10)If the ICMPv6 code is "Destination Unreachable" the implementation MAY mark the destination into the unreachable state or alternatively increment the path error counter. ************************************************************************* The path verification procedure end up as follows: ************************************************************************ --------- New text: (Section 5.4) --------- 5.4 Path Verification During association estabilishment the two peers exchange a list of addresses. In the predominant case these lists accurately represent the addresses owned by each peer. However there exists the possibility that a mis-behaving peer may supply addresses that it does not own. To prevent this the following rules are applied to all addresses of the new association: 1) Any address passed to the sender of the INIT by its upper layer is automatically considered to be CONFIRMED. 2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is the one that the INIT-ACK was sent to. 3) All other addresses not covered by rules 1 and 2 are considered UNCONFIRMED and are subject to probing for verification. To probe an address for verification, an endpoint will send HEARTBEAT's including a 64 bit random nonce and a path indicator (to identify the address that the HEARTBEAT is sent to) within the HEARTBEAT parameter. Upon reception of the HEARTBEAT-ACK a verification is made that the nonce included in the HEARTBEAT parameter is the one sent to the address indicated inside the HEARTBEAT parameter. When this match occurs, the address that the original HEARTBEAT was sent to is now considered CONFIRMED and available for normal data transfer. These probing proceedures are started when an association moves to the ESTABLISHED state and are ended when all paths are confirmed. Each RTO a probe may be sent on an active UNCONFIRMED path in an attempt to move it to to the CONFIRMED state. If during this probing the path becomes inactive this rate is lowered to the normal HEARTBEAT rate. At the expiration of the RTO timer the error counter of any path that was probed but not CONFIRMED is incremented by one and subjected to path failure detection defined in section 8.2. When probing UNCONFIRMED addresses, however, the association overall error count is NOT incremented. The number of HEARTBEATS sent at each RTO SHOULD be limited by the HB.Max.Burst parameter. It is an implementation decision as to how to distribute HEARTBEATS to the peers addresses for path verification. Whenever a path is confirmed an indication MAY be given to to the upper layer. An endpoint MUST NOT send any chunks to an UNCONFIRMED address with the following exceptions: - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED address. - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address. - A COOKIE-ACK MAY be sent to an UNCONFIRMED address but it MUST be bundled with a HEARTBEAT including a nonce. An implementation that does NOT support bundling MUST NOT send a COOKIE-ACK to an UNCONFIRMED address. - A COOKE-ECHO MAY be sent to an UNCONFIRMED address but it MUST be bundled with a HEARTBEAT including a nonce and the packet MUST NOT exceed the path MTU. If the implementation does NOT support bundling or the bundled COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed the path MTU, then the implemenation MUST NOT send a COOKIE-ECHO to an UNCONFIRMED address. ************************************************************* With the corresponding parameter defaults as follows: ************************************************************* The following protocol parameters are RECOMMENDED: RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds Max.Burst - 4 RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.Interval - 30 seconds HB.Max.Burst - 1 **************************************************************** I think this covers all that we had talked about... the byte amplification of INIT-ACK is mentioned/noted and I think we should move on... Implementations can minimize there INIT-ACK's as they deem appropriate and are now allowed to omit errors... Note, commens and suggested changes, as always, are most welcome :-D R -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 11 18:33:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPSgI-0002pk-Jt; Tue, 11 Oct 2005 18:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPSgG-0002pf-OM for tsvwg@megatron.ietf.org; Tue, 11 Oct 2005 18:33:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07733 for ; Tue, 11 Oct 2005 18:33:05 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[dMN0XRa+N5QmGp45xQoerczPbWrBeVVz]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPSqS-0003nJ-9E for tsvwg@ietf.org; Tue, 11 Oct 2005 18:43:41 -0400 Received: from ns.pigworks.openss7.net (IDENT:SLej8fjcJBGVzRVOxENyEEJAXqkszuQj@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j9BMWHc17164; Tue, 11 Oct 2005 16:32:17 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j9BMWGJ12471; Tue, 11 Oct 2005 16:32:16 -0600 Date: Tue, 11 Oct 2005 16:32:16 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051011163216.A12351@openss7.org> References: <20050921162304.A29088@openss7.org> <28d6f7b73746b7bbe5b706a75222ce50@lurchi.franken.de> <20050922045114.B6756@openss7.org> <69d50fe7d87f21c6298f1f561145c166@lurchi.franken.de> <20050923033810.B18747@openss7.org> <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> 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: <4346A997.5070300@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Fri, Oct 07, 2005 at 01:00:07PM -0400 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 j9BMWHc17164 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randall, On Fri, 07 Oct 2005, Randall Stewart wrote: > All: >=20 > In an attempt to draw this discussion and all the points > we have discussed to a close here is the text I am proposing > we add to the I-G. This I think covers all of our issues... >=20 > Our new section 11.5 now looks as follows: >=20 > ********************************************************* > --------- > New text > --------- >=20 > 11.5 Protection of non-SCTP capable hosts. >=20 > To provide non-SCTP capable host with the same level of > protection against attacks as SCTP capable ones all SCTP > stacks MUST implement the ICMP handling described in Appendix C. I think this is too broad. The Appendix is full of procedures for ignoring ICMP messages. I do not see how ignoring ICMP messages ever protects a non-SCTP capable host. Can this MUST be restricted to only those procedures in Appendix C that actually protect non-SCTP capable hosts? That is... hey! Where in the Appendix C below does it even say to stop on Protocol Unrechable? I can't find it there. >=20 > When an SCTP stack receives a packet containing multiple > control or DATA chunks and the processing of the packet > requires the sending of multiple chunks in response, > the sender of the response chunk('s) MUST NOT send > more than one packet. If bundling is supported multiple > response chunks that fit into a single packet MAY be > bundled together into one single response packet. If bundling > is not supported then the sender MUST NOT send more > than one response chunk and MUST discard all other > responses. Note that this rule does NOT apply to a > SACK chunk since a SACK chunk is, in itself, a response > to DATA and a SACK does not require a response of more DATA. >=20 > An SCTP implementation SHOULD abort the association if > it receives a SACK acknowledging a TSN which has not been sent. >=20 > An SCTP implementation that receives an INIT that would > require a large packet in response, due to the inclusion > of multiple ERROR parameters, MAY (at its discrection) > elect to omit some or all of the ERROR parameters > to reduce the size of the INIT-ACK. Due to a combination > of the size of the COOKIE parameter and the number > of addresses a receiver of an INIT may be indicating > to a peer, it is always possible that the INIT-ACK will > be larger than the original INIT. An SCTP implementation > SHOULD attempt to make the INIT-ACK as small as possible > to reduce the possibility of byte amplification attacks. Yes, this text is excellent. >=20 > ************************************************************* > The ICMP section that goes with it looks as follows: > ************************************************************* > --------- > New text: (Appendix C) > --------- >=20 > Appendix C ICMP Handling >=20 > Whenever an ICMP message is received by an SCTP endpoint the > following procedures MUST be followed to assure proper > utilization of the information being provided by layer 3. >=20 > ICMP1) Ignore all ICMPv4 messages where the type field is > not set to "Destination Unreachable". >=20 > ICMP2) Ignore all ICMPv6 messages where the type field is > not "Destination Unreachable, "Parameter Problem" or > "Packet Too Big". >=20 > ICMP3) Ignore any ICMPv4 messages where the code does not > indicate "Protocol Unreachable" or "Fragmentation Needed". >=20 > ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if > the code is not "Unrecognized next header type encountered". >=20 > ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the > association which sent the message that ICMP is responding to. > If the association cannot be found, ignore the ICMP message. >=20 > ICMP6) Validate that the verification tag contained in the ICMP > message matches the verification tag of the peer. > If the verification tag is not 0 and does NOT match, > discard the ICMP message. If it is 0 and the ICMP message conta= ins > enough bytes to verify that the chunk type is an INIT chunk > and that the initiate tag matches the tag of the peer continue > with ICMP7. If the ICMP message is too short, the chunk type > or the initiate tag does not match, silently discard the packet. >=20 > ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 > "Fragmentation Needed" process this information as defined for > PATH MTU discovery. >=20 > ICMP8) If the ICMP code is a "Unrecognized next header type > encountered" or a "Protocol Unreachable" treat this message > as an abort with the T bit set if it does not contain an > INIT chunk. If it does contain an INIT chunk and the associatio= n > is in COOKIE-WAIT state, handle the ICMP message like an ABORT. >=20 > ICMP9) If the ICMP code is an "Unrecognized next header type > encountered" or a "Protocol Unreachable" then the message > MUST be treated as an abort with the T bit set, checking > the Verification Tag in the ICMP message for validation. >=20 > ICMP10)If the ICMPv6 code is "Destination Unreachable" the > implementation MAY mark the destination into the unreachable > state or alternatively increment the path error counter. >=20 > ***********************************************************************= ** > The path verification procedure end up as follows: > ***********************************************************************= * > --------- > New text: (Section 5.4) > --------- > 5.4 Path Verification >=20 > During association estabilishment the two peers > exchange a list of addresses. In the predominant case > these lists accurately represent the addresses owned > by each peer. However there exists the possibility that > a mis-behaving peer may supply addresses that it does > not own. To prevent this the following rules are applied > to all addresses of the new association: >=20 > 1) Any address passed to the sender of the INIT by its > upper layer is automatically considered to be CONFIRMED. >=20 > 2) For the receiver of the COOKIE-ECHO the only CONFIRMED > address is the one that the INIT-ACK was sent to. >=20 > 3) All other addresses not covered by rules 1 and 2 are considered > UNCONFIRMED and are subject to probing for verification. >=20 > To probe an address for verification, an endpoint will send > HEARTBEAT's including a 64 bit random nonce and a path > indicator (to identify the address that the HEARTBEAT > is sent to) within the HEARTBEAT parameter. >=20 > Upon reception of the HEARTBEAT-ACK a verification is > made that the nonce included in the HEARTBEAT parameter > is the one sent to the address indicated inside the > HEARTBEAT parameter. When this match occurs, the address > that the original HEARTBEAT was sent to is now considered > CONFIRMED and available for normal data transfer. >=20 > These probing proceedures are started when an association > moves to the ESTABLISHED state and are ended when all > paths are confirmed. Above sounds good. >=20 > Each RTO a probe may be sent on an active UNCONFIRMED path > in an attempt to move it to to the CONFIRMED state. > If during this probing the path becomes inactive this rate > is lowered to the normal HEARTBEAT rate. At the expiration > of the RTO timer the error counter of any path that was > probed but not CONFIRMED is incremented by one and subjected > to path failure detection defined in section 8.2. When probing > UNCONFIRMED addresses, however, the association overall error count > is NOT incremented. Why not increment the association error count? Do we not want the association with bogus addresses in it to fail just as quickly as the one with all good addresses? I think the reverse might be desirable: that is to peg failures of unconfirmed addresses against the association at a faster rate (say double). I don't see any problem with applying the same policy with regard to association error peg counts to both confirmed and unconfirmed addresses. >=20 > The number of HEARTBEATS sent at each RTO SHOULD be limited > by the HB.Max.Burst parameter. It is an implementation decision > as to how to distribute HEARTBEATS to the peers addresses > for path verification. >=20 > Whenever a path is confirmed an indication MAY be given to > to the upper layer. >=20 > An endpoint MUST NOT send any chunks to an UNCONFIRMED > address with the following exceptions: >=20 > - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED > address. >=20 > - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address. >=20 > - A COOKIE-ACK MAY be sent to an UNCONFIRMED address but > it MUST be bundled with a HEARTBEAT including a nonce. > An implementation that does NOT support bundling MUST > NOT send a COOKIE-ACK to an UNCONFIRMED address. >=20 > - A COOKE-ECHO MAY be sent to an UNCONFIRMED address but > it MUST be bundled with a HEARTBEAT including a nonce > and the packet MUST NOT exceed the path MTU. If the > implementation does NOT support bundling or the bundled > COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed > the path MTU, then the implemenation MUST NOT send > a COOKIE-ECHO to an UNCONFIRMED address. We need to be able to send COOKIE-ACK,SACK,DATA in response to COOKIE-ECHO,DATA,[DATA]. Can we make this COOKIE-ACK,HB[nonce], SACK,DATA,[DATA] to unverified addresses. >=20 > ************************************************************* > With the corresponding parameter defaults as follows: > ************************************************************* > The following protocol parameters are RECOMMENDED: >=20 > RTO.Initial - 3 seconds > RTO.Min - 1 second > RTO.Max - 60 seconds > Max.Burst - 4 > RTO.Alpha - 1/8 > RTO.Beta - 1/4 > Valid.Cookie.Life - 60 seconds > Association.Max.Retrans - 10 attempts > Path.Max.Retrans - 5 attempts (per destination address) > Max.Init.Retransmits - 8 attempts > HB.Interval - 30 seconds > HB.Max.Burst - 1 >=20 > **************************************************************** >=20 >=20 > I think this covers all that we had talked about... the byte > amplification of INIT-ACK is mentioned/noted and I think > we should move on... Implementations can minimize there > INIT-ACK's as they deem appropriate and are now allowed > to omit errors... >=20 > Note, commens and suggested changes, as always, are most > welcome :-D Overall very good. Thank you for your wordsmithing efforts. --brian --=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 tsvwg-bounces@ietf.org Wed Oct 12 09:13:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgQ5-0007jM-B6; Wed, 12 Oct 2005 09:13:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgQ3-0007hl-AW for tsvwg@megatron.ietf.org; Wed, 12 Oct 2005 09:13:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20351 for ; Wed, 12 Oct 2005 09:13:16 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPgaM-0001pR-F4 for tsvwg@ietf.org; Wed, 12 Oct 2005 09:23:59 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j9CDCv9c023993; Wed, 12 Oct 2005 15:12:57 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9CDCugt002846; Wed, 12 Oct 2005 15:12:56 +0200 Received: from MCHP7I6A.ww002.siemens.net ([139.25.131.137]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Oct 2005 15:12:48 +0200 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Tsvwg] ICMP issue with SCTP IG Date: Wed, 12 Oct 2005 15:12:47 +0200 Message-ID: Thread-Topic: [Tsvwg] ICMP issue with SCTP IG Thread-Index: AcXOn86mMppIBgMNSXuZ4TDS/zQIuwAjneGg From: "Meyknecht, Bernward" To: "Randall Stewart" , "Michael Tuexen" , X-OriginalArrivalTime: 12 Oct 2005 13:12:48.0524 (UTC) FILETIME=[A4803CC0:01C5CF2E] X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Content-Transfer-Encoding: quoted-printable Cc: bidulock@openss7.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org =20 Hi all, I'm not content with the new section on ICMP handling for the SCTP IG, = incl.=20 the 'MUST' for ICMP handling within an SCTP specification, and propose = to replace=20 it by a weaker wording and moving the section to another place. I would of course never propose to delete the ICMP section from the IG, = but for me=20 it is something to be described in an appendix of the SCTP = specification, as it is=20 done in the actual issue 15 of the IG, without the wording 'MUST', but = with=20 something like '...should be followed to assure proper utilization of = the information=20 being provided by layer 3', which is the current wording. Adding ICMP handling to SCTP was motivated by attack scenarios described = in the=20 draft draft-stewart-tsvwg-sctpthreat-03.txt, okay. But the other enhancements being described for SCTP within the new IG = section,=20 i.e. amplification control, path verification (small hb.max.burst) and = aborting=20 when receiving an ack for an unsent TSN, etc. these are exactlay the counter measures taken on SCTP level to prevent = the=20 attacks. Besides that there is a number of circumstances on which the = attacks=20 depend, i.e. which are necessary to allow the attack at all. With an SCTP implementation having the SCTP enhancements as mentioned = above I=20 don't see the relevance of these attacks on SCTP any more. Besides that I see ICMP as something belonging to a layer below SCTP, = the SCTP=20 RFC should describe only the SCTP level, hints on ICMP handling could be = part of an extra document/draft, even in a future RFC. Kind regards, Bernward -----Urspr=FCngliche Nachricht----- Von: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] Im Auftrag = von Randall Stewart Gesendet: Freitag, 7. Oktober 2005 19:00 An: Michael Tuexen Cc: bidulock@openss7.org; tsvwg@ietf.org; Vlad Yasevich; Coene, Lode; = Schruefer, Wolfgang; Kacheong Poon; Scott Bradner Betreff: Re: [Tsvwg] ICMP issue with SCTP IG All: In an attempt to draw this discussion and all the points we have discussed to a close here is the text I am proposing we add to the I-G. This I think covers all of our issues... Our new section 11.5 now looks as follows: ********************************************************* --------- New text --------- 11.5 Protection of non-SCTP capable hosts. To provide non-SCTP capable host with the same level of protection against attacks as SCTP capable ones all SCTP stacks MUST implement the ICMP handling described in Appendix C. When an SCTP stack receives a packet containing multiple control or DATA chunks and the processing of the packet requires the sending of multiple chunks in response, the sender of the response chunk('s) MUST NOT send more than one packet. If bundling is supported multiple response chunks that fit into a single packet MAY be bundled together into one single response packet. If bundling is not supported then the sender MUST NOT send more than one response chunk and MUST discard all other responses. Note that this rule does NOT apply to a SACK chunk since a SACK chunk is, in itself, a response to DATA and a SACK does not require a response of more DATA. An SCTP implementation SHOULD abort the association if it receives a SACK acknowledging a TSN which has not been sent. An SCTP implementation that receives an INIT that would require a large packet in response, due to the inclusion of multiple ERROR parameters, MAY (at its discrection) elect to omit some or all of the ERROR parameters to reduce the size of the INIT-ACK. Due to a combination of the size of the COOKIE parameter and the number of addresses a receiver of an INIT may be indicating to a peer, it is always possible that the INIT-ACK will be larger than the original INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as small as possible to reduce the possibility of byte amplification attacks. ************************************************************* The ICMP section that goes with it looks as follows: ************************************************************* --------- New text: (Appendix C) --------- Appendix C ICMP Handling Whenever an ICMP message is received by an SCTP endpoint the following procedures MUST be followed to assure proper utilization of the information being provided by layer 3. ICMP1) Ignore all ICMPv4 messages where the type field is not set to "Destination Unreachable". ICMP2) Ignore all ICMPv6 messages where the type field is not "Destination Unreachable, "Parameter Problem" or "Packet Too Big". ICMP3) Ignore any ICMPv4 messages where the code does not indicate "Protocol Unreachable" or "Fragmentation Needed". ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if the code is not "Unrecognized next header type encountered". ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the association which sent the message that ICMP is responding to. If the association cannot be found, ignore the ICMP message. ICMP6) Validate that the verification tag contained in the ICMP message matches the verification tag of the peer. If the verification tag is not 0 and does NOT match, discard the ICMP message. If it is 0 and the ICMP message = contains enough bytes to verify that the chunk type is an INIT chunk and that the initiate tag matches the tag of the peer continue with ICMP7. If the ICMP message is too short, the chunk type or the initiate tag does not match, silently discard the packet. ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 "Fragmentation Needed" process this information as defined for PATH MTU discovery. ICMP8) If the ICMP code is a "Unrecognized next header type encountered" or a "Protocol Unreachable" treat this message as an abort with the T bit set if it does not contain an INIT chunk. If it does contain an INIT chunk and the association is in COOKIE-WAIT state, handle the ICMP message like an ABORT. ICMP9) If the ICMP code is an "Unrecognized next header type encountered" or a "Protocol Unreachable" then the message MUST be treated as an abort with the T bit set, checking the Verification Tag in the ICMP message for validation. ICMP10)If the ICMPv6 code is "Destination Unreachable" the implementation MAY mark the destination into the unreachable state or alternatively increment the path error counter. *************************************************************************= The path verification procedure end up as follows: ************************************************************************ --------- New text: (Section 5.4) --------- 5.4 Path Verification During association estabilishment the two peers exchange a list of addresses. In the predominant case these lists accurately represent the addresses owned by each peer. However there exists the possibility that a mis-behaving peer may supply addresses that it does not own. To prevent this the following rules are applied to all addresses of the new association: 1) Any address passed to the sender of the INIT by its upper layer is automatically considered to be CONFIRMED. 2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is the one that the INIT-ACK was sent to. 3) All other addresses not covered by rules 1 and 2 are considered UNCONFIRMED and are subject to probing for verification. To probe an address for verification, an endpoint will send HEARTBEAT's including a 64 bit random nonce and a path indicator (to identify the address that the HEARTBEAT is sent to) within the HEARTBEAT parameter. Upon reception of the HEARTBEAT-ACK a verification is made that the nonce included in the HEARTBEAT parameter is the one sent to the address indicated inside the HEARTBEAT parameter. When this match occurs, the address that the original HEARTBEAT was sent to is now considered CONFIRMED and available for normal data transfer. These probing proceedures are started when an association moves to the ESTABLISHED state and are ended when all paths are confirmed. Each RTO a probe may be sent on an active UNCONFIRMED path in an attempt to move it to to the CONFIRMED state. If during this probing the path becomes inactive this rate is lowered to the normal HEARTBEAT rate. At the expiration of the RTO timer the error counter of any path that was probed but not CONFIRMED is incremented by one and subjected to path failure detection defined in section 8.2. When probing UNCONFIRMED addresses, however, the association overall error count is NOT incremented. The number of HEARTBEATS sent at each RTO SHOULD be limited by the HB.Max.Burst parameter. It is an implementation decision as to how to distribute HEARTBEATS to the peers addresses for path verification. Whenever a path is confirmed an indication MAY be given to to the upper layer. An endpoint MUST NOT send any chunks to an UNCONFIRMED address with the following exceptions: - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED address. - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address. - A COOKIE-ACK MAY be sent to an UNCONFIRMED address but it MUST be bundled with a HEARTBEAT including a nonce. An implementation that does NOT support bundling MUST NOT send a COOKIE-ACK to an UNCONFIRMED address. - A COOKE-ECHO MAY be sent to an UNCONFIRMED address but it MUST be bundled with a HEARTBEAT including a nonce and the packet MUST NOT exceed the path MTU. If the implementation does NOT support bundling or the bundled COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed the path MTU, then the implemenation MUST NOT send a COOKIE-ECHO to an UNCONFIRMED address. ************************************************************* With the corresponding parameter defaults as follows: ************************************************************* The following protocol parameters are RECOMMENDED: RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds Max.Burst - 4 RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.Interval - 30 seconds HB.Max.Burst - 1 **************************************************************** I think this covers all that we had talked about... the byte amplification of INIT-ACK is mentioned/noted and I think we should move on... Implementations can minimize there INIT-ACK's as they deem appropriate and are now allowed to omit errors... Note, commens and suggested changes, as always, are most welcome :-D R --=20 Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ 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 tsvwg-bounces@ietf.org Wed Oct 12 11:04:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPi9p-0002t6-Ig; Wed, 12 Oct 2005 11:04:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPi9l-0002q1-Gx for tsvwg@megatron.ietf.org; Wed, 12 Oct 2005 11:04:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26786 for ; Wed, 12 Oct 2005 11:04:34 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPiK5-00057S-7e for tsvwg@ietf.org; Wed, 12 Oct 2005 11:15:18 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2005 17:04:28 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9CF3kHp028846; Wed, 12 Oct 2005 17:04:23 +0200 (MEST) Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Oct 2005 17:04:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Oct 2005 17:04:18 +0200 Message-ID: Thread-Topic: WG Last Call on draft-tsvwg-rsvp-dste-00.txt Thread-Index: AcXAHxBHCLGnoXNqRcqN2ojBoX1cagPHZmqQ From: "Francois Le Faucheur \(flefauch\)" To: "Allison Mankin" , "Peterson, Jon" X-OriginalArrivalTime: 12 Oct 2005 15:04:19.0350 (UTC) FILETIME=[388B4360:01C5CF3E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: gash@att.com, Davenport Michael , tsvwg@ietf.org, Christou Chris Subject: [Tsvwg] WG Last Call on draft-tsvwg-rsvp-dste-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hello Allison, Jon, I understand the decision at last meeting was to issue a WG Last Call on and make sure that, as part of the WGLC, at least a couple of "RSVP Team" members write up their reviews. Could we go ahead with the LC? Could you help identify who from the "RSVP Team" can commit to written reviews? That way we could work face to face in Vancouver to close potential comments/issues from the review. =20 Thank you =20 Francois =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >From draft minutes: " >> Allison said that she is willing to have a WGLC, but the WG=20 >> needs to have written reviews from the people that call=20 >> themselves the "RSVP team". >> Any objections? No one voiced objections. >>=20 >> Allson called for a hum: People supporting wglc at this time? >> There was moderate support Allison declares enough support=20 >> to go ahead. The requirement will >> be a least a couple of RSVP reviewers (from the RSVP team)=20 >> to write during WGLC. " _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Oct 12 15:43:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPmVw-0001vv-CF; Wed, 12 Oct 2005 15:43:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPmVt-0001vg-1A for tsvwg@megatron.ietf.org; Wed, 12 Oct 2005 15:43:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14161 for ; Wed, 12 Oct 2005 15:43:42 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPmgD-0005Eb-Ky for tsvwg@ietf.org; Wed, 12 Oct 2005 15:54:28 -0400 Received: from [192.168.1.15] (p508F5C3B.dip.t-dialin.net [80.143.92.59]) by ilsa.franken.de (Postfix) with ESMTP id 923D4245C9; Wed, 12 Oct 2005 21:43:23 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <4346A997.5070300@stewart.chicago.il.us> References: <260bfb19542b53463de0c3410fc4badc@lurchi.franken.de> <43305CE9.1000408@stewart.chicago.il.us> <20050921015053.A10788@openss7.org> <40738d159d9c90c6d69f7ee3e6210db1@lurchi.franken.de> <20050921111932.A26114@openss7.org> <20050921162304.A29088@openss7.org> <28d6f7b73746b7bbe5b706a75222ce50@lurchi.franken.de> <20050922045114.B6756@openss7.org> <69d50fe7d87f21c6298f1f561145c166@lurchi.franken.de> <20050923033810.B18747@openss7.org> <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Wed, 12 Oct 2005 21:43:21 +0200 To: Randall Stewart X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.2 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Content-Transfer-Encoding: 7bit Cc: bidulock@openss7.org, tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randy, in general I like the text you submitted. But I think it might be good to have the SCTP procedure in tune with the ones described in RFC 1122 (Host Requirements). Section 3.2.2.1 of RFC 1122 states A host SHOULD generate Destination Unreachable messages with code: 2 (Protocol Unreachable), when the designated transport protocol is not supported; A Destination Unreachable message that is received MUST be reported to the transport layer. The transport layer SHOULD use the information appropriately; for example, see Sections 4.1.3.3, 4.2.3.9, and 4.2.4 below. and section 4.2.3.9 states (for TCP) o Destination Unreachable -- codes 2-4 These are hard error conditions, so TCP SHOULD abort the connection. So I think to harmonize the future SCTP RFC with RFC 1122, we should change ICMP9) If the ICMP code is an "Unrecognized next header type encountered" or a "Protocol Unreachable" then the message MUST be treated as an abort with the T bit set, checking the Verification Tag in the ICMP message for validation. to ICMP9) If the ICMP code is an "Unrecognized next header type encountered" or a "Protocol Unreachable" then the message SHOULD be treated as an abort with the T bit set, checking the Verification Tag in the ICMP message for validation. Furthermore RFC 1122 states in section 3.2.2.1 A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose. This covers SCTP too. So we should either add this rule to the ICMP processing rules or make an Implementation Note that we do not require an SCTP implementation to do it. I would prefer the second, because either the receiver of an INIT supports SCTP and sends back an ABORT or does not support SCTP and sends back an ICMP(protocol unreachable). So an ICMP(port unreachable) should never be generated. So I would like to make an explicit statement, that an SCTP implementation SHOULD not process an ICMP(port unreachable). What do you and others think? Best regards Michael On Oct 7, 2005, at 7:00 PM, Randall Stewart wrote: > All: > > In an attempt to draw this discussion and all the points > we have discussed to a close here is the text I am proposing > we add to the I-G. This I think covers all of our issues... > > Our new section 11.5 now looks as follows: > > ********************************************************* > --------- > New text > --------- > > 11.5 Protection of non-SCTP capable hosts. > > To provide non-SCTP capable host with the same level of > protection against attacks as SCTP capable ones all SCTP > stacks MUST implement the ICMP handling described in Appendix C. > > When an SCTP stack receives a packet containing multiple > control or DATA chunks and the processing of the packet > requires the sending of multiple chunks in response, > the sender of the response chunk('s) MUST NOT send > more than one packet. If bundling is supported multiple > response chunks that fit into a single packet MAY be > bundled together into one single response packet. If bundling > is not supported then the sender MUST NOT send more > than one response chunk and MUST discard all other > responses. Note that this rule does NOT apply to a > SACK chunk since a SACK chunk is, in itself, a response > to DATA and a SACK does not require a response of more DATA. > > An SCTP implementation SHOULD abort the association if > it receives a SACK acknowledging a TSN which has not been sent. > > An SCTP implementation that receives an INIT that would > require a large packet in response, due to the inclusion > of multiple ERROR parameters, MAY (at its discrection) > elect to omit some or all of the ERROR parameters > to reduce the size of the INIT-ACK. Due to a combination > of the size of the COOKIE parameter and the number > of addresses a receiver of an INIT may be indicating > to a peer, it is always possible that the INIT-ACK will > be larger than the original INIT. An SCTP implementation > SHOULD attempt to make the INIT-ACK as small as possible > to reduce the possibility of byte amplification attacks. > > ************************************************************* > The ICMP section that goes with it looks as follows: > ************************************************************* > --------- > New text: (Appendix C) > --------- > > Appendix C ICMP Handling > > Whenever an ICMP message is received by an SCTP endpoint the > following procedures MUST be followed to assure proper > utilization of the information being provided by layer 3. > > ICMP1) Ignore all ICMPv4 messages where the type field is > not set to "Destination Unreachable". > > ICMP2) Ignore all ICMPv6 messages where the type field is > not "Destination Unreachable, "Parameter Problem" or > "Packet Too Big". > > ICMP3) Ignore any ICMPv4 messages where the code does not > indicate "Protocol Unreachable" or "Fragmentation Needed". > > ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if > the code is not "Unrecognized next header type encountered". > > ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the > association which sent the message that ICMP is responding to. > If the association cannot be found, ignore the ICMP message. > > ICMP6) Validate that the verification tag contained in the ICMP > message matches the verification tag of the peer. > If the verification tag is not 0 and does NOT match, > discard the ICMP message. If it is 0 and the ICMP message > contains > enough bytes to verify that the chunk type is an INIT chunk > and that the initiate tag matches the tag of the peer continue > with ICMP7. If the ICMP message is too short, the chunk type > or the initiate tag does not match, silently discard the > packet. > > ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 > "Fragmentation Needed" process this information as defined for > PATH MTU discovery. > > ICMP8) If the ICMP code is a "Unrecognized next header type > encountered" or a "Protocol Unreachable" treat this message > as an abort with the T bit set if it does not contain an > INIT chunk. If it does contain an INIT chunk and the > association > is in COOKIE-WAIT state, handle the ICMP message like an ABORT. > > ICMP9) If the ICMP code is an "Unrecognized next header type > encountered" or a "Protocol Unreachable" then the message > MUST be treated as an abort with the T bit set, checking > the Verification Tag in the ICMP message for validation. > > ICMP10)If the ICMPv6 code is "Destination Unreachable" the > implementation MAY mark the destination into the unreachable > state or alternatively increment the path error counter. > > ********************************************************************** > *** > The path verification procedure end up as follows: > ********************************************************************** > ** > --------- > New text: (Section 5.4) > --------- > 5.4 Path Verification > > During association estabilishment the two peers > exchange a list of addresses. In the predominant case > these lists accurately represent the addresses owned > by each peer. However there exists the possibility that > a mis-behaving peer may supply addresses that it does > not own. To prevent this the following rules are applied > to all addresses of the new association: > > 1) Any address passed to the sender of the INIT by its > upper layer is automatically considered to be CONFIRMED. > > 2) For the receiver of the COOKIE-ECHO the only CONFIRMED > address is the one that the INIT-ACK was sent to. > > 3) All other addresses not covered by rules 1 and 2 are considered > UNCONFIRMED and are subject to probing for verification. > > To probe an address for verification, an endpoint will send > HEARTBEAT's including a 64 bit random nonce and a path > indicator (to identify the address that the HEARTBEAT > is sent to) within the HEARTBEAT parameter. > > Upon reception of the HEARTBEAT-ACK a verification is > made that the nonce included in the HEARTBEAT parameter > is the one sent to the address indicated inside the > HEARTBEAT parameter. When this match occurs, the address > that the original HEARTBEAT was sent to is now considered > CONFIRMED and available for normal data transfer. > > These probing proceedures are started when an association > moves to the ESTABLISHED state and are ended when all > paths are confirmed. > > Each RTO a probe may be sent on an active UNCONFIRMED path > in an attempt to move it to to the CONFIRMED state. > If during this probing the path becomes inactive this rate > is lowered to the normal HEARTBEAT rate. At the expiration > of the RTO timer the error counter of any path that was > probed but not CONFIRMED is incremented by one and subjected > to path failure detection defined in section 8.2. When probing > UNCONFIRMED addresses, however, the association overall error count > is NOT incremented. > > The number of HEARTBEATS sent at each RTO SHOULD be limited > by the HB.Max.Burst parameter. It is an implementation decision > as to how to distribute HEARTBEATS to the peers addresses > for path verification. > > Whenever a path is confirmed an indication MAY be given to > to the upper layer. > > An endpoint MUST NOT send any chunks to an UNCONFIRMED > address with the following exceptions: > > - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED > address. > > - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address. > > - A COOKIE-ACK MAY be sent to an UNCONFIRMED address but > it MUST be bundled with a HEARTBEAT including a nonce. > An implementation that does NOT support bundling MUST > NOT send a COOKIE-ACK to an UNCONFIRMED address. > > - A COOKE-ECHO MAY be sent to an UNCONFIRMED address but > it MUST be bundled with a HEARTBEAT including a nonce > and the packet MUST NOT exceed the path MTU. If the > implementation does NOT support bundling or the bundled > COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed > the path MTU, then the implemenation MUST NOT send > a COOKIE-ECHO to an UNCONFIRMED address. > > ************************************************************* > With the corresponding parameter defaults as follows: > ************************************************************* > The following protocol parameters are RECOMMENDED: > > RTO.Initial - 3 seconds > RTO.Min - 1 second > RTO.Max - 60 seconds > Max.Burst - 4 > RTO.Alpha - 1/8 > RTO.Beta - 1/4 > Valid.Cookie.Life - 60 seconds > Association.Max.Retrans - 10 attempts > Path.Max.Retrans - 5 attempts (per destination address) > Max.Init.Retransmits - 8 attempts > HB.Interval - 30 seconds > HB.Max.Burst - 1 > > **************************************************************** > > > I think this covers all that we had talked about... the byte > amplification of INIT-ACK is mentioned/noted and I think > we should move on... Implementations can minimize there > INIT-ACK's as they deem appropriate and are now allowed > to omit errors... > > Note, commens and suggested changes, as always, are most > welcome :-D > > R > > -- > Randall Stewart > 803-345-0369 815-342-5222(cell) > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Oct 12 16:48:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnWN-0008J0-3z; Wed, 12 Oct 2005 16:48:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnWL-0008In-LV for tsvwg@megatron.ietf.org; Wed, 12 Oct 2005 16:48:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04545 for ; Wed, 12 Oct 2005 16:48:14 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPngi-0004hJ-KC for tsvwg@ietf.org; Wed, 12 Oct 2005 16:59:01 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j9CKlt7i027579; Wed, 12 Oct 2005 22:47:55 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j9CKlsHs011965; Wed, 12 Oct 2005 22:47:54 +0200 Received: from MCHP7I6A.ww002.siemens.net ([139.25.131.137]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Oct 2005 22:47:54 +0200 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Tsvwg] ICMP issue with SCTP IG Date: Wed, 12 Oct 2005 22:47:41 +0200 Message-ID: Thread-Topic: [Tsvwg] ICMP issue with SCTP IG Thread-Index: AcXPZbztOe9dkvbFSRSyJxmCrIJFHAABY99g From: "Meyknecht, Bernward" To: "Michael Tuexen" , "Randall Stewart" X-OriginalArrivalTime: 12 Oct 2005 20:47:54.0535 (UTC) FILETIME=[3826DB70:01C5CF6E] X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Content-Transfer-Encoding: quoted-printable Cc: bidulock@openss7.org, tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org =20 Hello Michael, Randy, I agree to the harmonization with RFC 1122 (a good point) and to this = proposal,=20 i.e. changing the ICMP9 and making the implementation note on not = processig=20 an ICMP(port unreachable). With that change, the text for section 11.5 would be fine and I like it. Kind regards, Bernward -----Urspr=FCngliche Nachricht----- Von: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] Im Auftrag = von Michael Tuexen Gesendet: Mittwoch, 12. Oktober 2005 21:43 An: Randall Stewart Cc: bidulock@openss7.org; tsvwg@ietf.org; Vlad Yasevich; Coene, Lode; = Schruefer, Wolfgang; Kacheong Poon; Scott Bradner Betreff: Re: [Tsvwg] ICMP issue with SCTP IG Randy, in general I like the text you submitted. But I think it might be good to have the SCTP procedure in tune with the ones described in RFC 1122 (Host Requirements). Section 3.2.2.1 of RFC 1122 states A host SHOULD generate Destination Unreachable messages =20 with code: 2 (Protocol Unreachable), when the designated transport protocol is not supported; A Destination Unreachable message that is received MUST be reported to the transport layer. The transport layer =20 SHOULD use the information appropriately; for example, see =20 Sections 4.1.3.3, 4.2.3.9, and 4.2.4 below. and section 4.2.3.9 states (for TCP) o Destination Unreachable -- codes 2-4 These are hard error conditions, so TCP SHOULD abort the connection. So I think to harmonize the future SCTP RFC with RFC 1122, we should =20 change ICMP9) If the ICMP code is an "Unrecognized next header type encountered" or a "Protocol Unreachable" then the message MUST be treated as an abort with the T bit set, checking the Verification Tag in the ICMP message for validation. to ICMP9) If the ICMP code is an "Unrecognized next header type encountered" or a "Protocol Unreachable" then the message SHOULD be treated as an abort with the T bit set, checking the Verification Tag in the ICMP message for validation. Furthermore RFC 1122 states in section 3.2.2.1 A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose. This covers SCTP too. So we should either add this rule to the ICMP =20 processing rules or make an Implementation Note that we do not require an SCTP =20 implementation to do it. I would prefer the second, because either the receiver of =20 an INIT supports SCTP and sends back an ABORT or does not support SCTP and sends back an ICMP(protocol unreachable). So an ICMP(port unreachable) should never =20 be generated. So I would like to make an explicit statement, that an SCTP =20 implementation SHOULD not process an ICMP(port unreachable). What do you and others think? Best regards Michael On Oct 7, 2005, at 7:00 PM, Randall Stewart wrote: > All: > > In an attempt to draw this discussion and all the points > we have discussed to a close here is the text I am proposing > we add to the I-G. This I think covers all of our issues... > > Our new section 11.5 now looks as follows: > > ********************************************************* > --------- > New text > --------- > > 11.5 Protection of non-SCTP capable hosts. > > To provide non-SCTP capable host with the same level of > protection against attacks as SCTP capable ones all SCTP > stacks MUST implement the ICMP handling described in Appendix C. > > When an SCTP stack receives a packet containing multiple > control or DATA chunks and the processing of the packet > requires the sending of multiple chunks in response, > the sender of the response chunk('s) MUST NOT send > more than one packet. If bundling is supported multiple > response chunks that fit into a single packet MAY be > bundled together into one single response packet. If bundling > is not supported then the sender MUST NOT send more > than one response chunk and MUST discard all other > responses. Note that this rule does NOT apply to a > SACK chunk since a SACK chunk is, in itself, a response > to DATA and a SACK does not require a response of more DATA. > > An SCTP implementation SHOULD abort the association if > it receives a SACK acknowledging a TSN which has not been sent. > > An SCTP implementation that receives an INIT that would > require a large packet in response, due to the inclusion > of multiple ERROR parameters, MAY (at its discrection) > elect to omit some or all of the ERROR parameters > to reduce the size of the INIT-ACK. Due to a combination > of the size of the COOKIE parameter and the number > of addresses a receiver of an INIT may be indicating > to a peer, it is always possible that the INIT-ACK will > be larger than the original INIT. An SCTP implementation > SHOULD attempt to make the INIT-ACK as small as possible > to reduce the possibility of byte amplification attacks. > > ************************************************************* > The ICMP section that goes with it looks as follows: > ************************************************************* > --------- > New text: (Appendix C) > --------- > > Appendix C ICMP Handling > > Whenever an ICMP message is received by an SCTP endpoint the > following procedures MUST be followed to assure proper > utilization of the information being provided by layer 3. > > ICMP1) Ignore all ICMPv4 messages where the type field is > not set to "Destination Unreachable". > > ICMP2) Ignore all ICMPv6 messages where the type field is > not "Destination Unreachable, "Parameter Problem" or > "Packet Too Big". > > ICMP3) Ignore any ICMPv4 messages where the code does not > indicate "Protocol Unreachable" or "Fragmentation Needed". > > ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if > the code is not "Unrecognized next header type encountered". > > ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the > association which sent the message that ICMP is responding to. > If the association cannot be found, ignore the ICMP message. > > ICMP6) Validate that the verification tag contained in the ICMP > message matches the verification tag of the peer. > If the verification tag is not 0 and does NOT match, > discard the ICMP message. If it is 0 and the ICMP message =20 > contains > enough bytes to verify that the chunk type is an INIT chunk > and that the initiate tag matches the tag of the peer continue > with ICMP7. If the ICMP message is too short, the chunk type > or the initiate tag does not match, silently discard the =20 > packet. > > ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 > "Fragmentation Needed" process this information as defined for > PATH MTU discovery. > > ICMP8) If the ICMP code is a "Unrecognized next header type > encountered" or a "Protocol Unreachable" treat this message > as an abort with the T bit set if it does not contain an > INIT chunk. If it does contain an INIT chunk and the =20 > association > is in COOKIE-WAIT state, handle the ICMP message like an ABORT. > > ICMP9) If the ICMP code is an "Unrecognized next header type > encountered" or a "Protocol Unreachable" then the message > MUST be treated as an abort with the T bit set, checking > the Verification Tag in the ICMP message for validation. > > ICMP10)If the ICMPv6 code is "Destination Unreachable" the > implementation MAY mark the destination into the unreachable > state or alternatively increment the path error counter. > > ********************************************************************** = > *** > The path verification procedure end up as follows: > ********************************************************************** = > ** > --------- > New text: (Section 5.4) > --------- > 5.4 Path Verification > > During association estabilishment the two peers > exchange a list of addresses. In the predominant case > these lists accurately represent the addresses owned > by each peer. However there exists the possibility that > a mis-behaving peer may supply addresses that it does > not own. To prevent this the following rules are applied > to all addresses of the new association: > > 1) Any address passed to the sender of the INIT by its > upper layer is automatically considered to be CONFIRMED. > > 2) For the receiver of the COOKIE-ECHO the only CONFIRMED > address is the one that the INIT-ACK was sent to. > > 3) All other addresses not covered by rules 1 and 2 are considered > UNCONFIRMED and are subject to probing for verification. > > To probe an address for verification, an endpoint will send > HEARTBEAT's including a 64 bit random nonce and a path > indicator (to identify the address that the HEARTBEAT > is sent to) within the HEARTBEAT parameter. > > Upon reception of the HEARTBEAT-ACK a verification is > made that the nonce included in the HEARTBEAT parameter > is the one sent to the address indicated inside the > HEARTBEAT parameter. When this match occurs, the address > that the original HEARTBEAT was sent to is now considered > CONFIRMED and available for normal data transfer. > > These probing proceedures are started when an association > moves to the ESTABLISHED state and are ended when all > paths are confirmed. > > Each RTO a probe may be sent on an active UNCONFIRMED path > in an attempt to move it to to the CONFIRMED state. > If during this probing the path becomes inactive this rate > is lowered to the normal HEARTBEAT rate. At the expiration > of the RTO timer the error counter of any path that was > probed but not CONFIRMED is incremented by one and subjected > to path failure detection defined in section 8.2. When probing > UNCONFIRMED addresses, however, the association overall error count > is NOT incremented. > > The number of HEARTBEATS sent at each RTO SHOULD be limited > by the HB.Max.Burst parameter. It is an implementation decision > as to how to distribute HEARTBEATS to the peers addresses > for path verification. > > Whenever a path is confirmed an indication MAY be given to > to the upper layer. > > An endpoint MUST NOT send any chunks to an UNCONFIRMED > address with the following exceptions: > > - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED > address. > > - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address. > > - A COOKIE-ACK MAY be sent to an UNCONFIRMED address but > it MUST be bundled with a HEARTBEAT including a nonce. > An implementation that does NOT support bundling MUST > NOT send a COOKIE-ACK to an UNCONFIRMED address. > > - A COOKE-ECHO MAY be sent to an UNCONFIRMED address but > it MUST be bundled with a HEARTBEAT including a nonce > and the packet MUST NOT exceed the path MTU. If the > implementation does NOT support bundling or the bundled > COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed > the path MTU, then the implemenation MUST NOT send > a COOKIE-ECHO to an UNCONFIRMED address. > > ************************************************************* > With the corresponding parameter defaults as follows: > ************************************************************* > The following protocol parameters are RECOMMENDED: > > RTO.Initial - 3 seconds > RTO.Min - 1 second > RTO.Max - 60 seconds > Max.Burst - 4 > RTO.Alpha - 1/8 > RTO.Beta - 1/4 > Valid.Cookie.Life - 60 seconds > Association.Max.Retrans - 10 attempts > Path.Max.Retrans - 5 attempts (per destination address) > Max.Init.Retransmits - 8 attempts > HB.Interval - 30 seconds > HB.Max.Burst - 1 > > **************************************************************** > > > I think this covers all that we had talked about... the byte > amplification of INIT-ACK is mentioned/noted and I think > we should move on... Implementations can minimize there > INIT-ACK's as they deem appropriate and are now allowed > to omit errors... > > Note, commens and suggested changes, as always, are most > welcome :-D > > R > > --=20 > Randall Stewart > 803-345-0369 815-342-5222(cell) > > > _______________________________________________ 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 tsvwg-bounces@ietf.org Wed Oct 12 19:32:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPq5X-00076A-GK; Wed, 12 Oct 2005 19:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPq5W-000765-Ci for tsvwg@megatron.ietf.org; Wed, 12 Oct 2005 19:32:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11949 for ; Wed, 12 Oct 2005 19:32:42 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[5MM8lM4apGCOAEmskr2V6aUuR4M68umu]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPqFv-00009F-Hr for tsvwg@ietf.org; Wed, 12 Oct 2005 19:43:31 -0400 Received: from ns.pigworks.openss7.net (IDENT:M6G2W09yw+8Zg/OLxmDl5jImSN2Kl4kr@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j9CNWFc13961; Wed, 12 Oct 2005 17:32:15 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j9CNWED30792; Wed, 12 Oct 2005 17:32:14 -0600 Date: Wed, 12 Oct 2005 17:32:13 -0600 From: "Brian F. G. Bidulock" To: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051012173213.D29834@openss7.org> References: <20050921162304.A29088@openss7.org> <28d6f7b73746b7bbe5b706a75222ce50@lurchi.franken.de> <20050922045114.B6756@openss7.org> <69d50fe7d87f21c6298f1f561145c166@lurchi.franken.de> <20050923033810.B18747@openss7.org> <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> 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: <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de>; from Michael.Tuexen@lurchi.franken.de on Wed, Oct 12, 2005 at 09:43:21PM +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 j9CNWFc13961 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Randall Stewart , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael, On Wed, 12 Oct 2005, Michael Tuexen wrote: > to do it. I would prefer the second, because either the receiver of =20 > an INIT supports > SCTP and sends back an ABORT or does not support SCTP and sends back an > ICMP(protocol unreachable). So an ICMP(port unreachable) should never =20 > be generated. > So I would like to make an explicit statement, that an SCTP =20 > implementation SHOULD > not process an ICMP(port unreachable). >=20 > What do you and others think? Could not an ICMP(port unreachable) be generated by a middlebox or firewall (i.e. port proxy). --brian --=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 tsvwg-bounces@ietf.org Thu Oct 13 00:08:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPuNw-0004sQ-D2; Thu, 13 Oct 2005 00:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPuNu-0004sL-Hp for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 00:08:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21868 for ; Thu, 13 Oct 2005 00:07:58 -0400 (EDT) Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPuY6-0005qY-R5 for tsvwg@ietf.org; Thu, 13 Oct 2005 00:18:38 -0400 Received: from [10.0.1.5] (dsl081-036-151.lax1.dsl.speakeasy.net [64.81.36.151]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9D46lO24357; Wed, 12 Oct 2005 21:06:47 -0700 (PDT) Date: Wed, 12 Oct 2005 21:06:45 -0700 From: Aaron Falk To: "Francois Le Faucheur (flefauch)" , Allison Mankin , "Peterson, Jon" Subject: Re: [Tsvwg] WG Last Call on draft-tsvwg-rsvp-dste-00.txt Message-ID: <1751F2DD09BCDC64D1AD668D@nak.isi.edu> In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: gash@att.com, Davenport Michael , tsvwg@ietf.org, Christou Chris X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Francois- My (admittedly vague) recollection is that the expert writeup was a pre-requisite to WGLC, not part of WGLC. --aaron --On October 12, 2005 5:04:18 PM +0200 "Francois Le Faucheur (flefauch)" wrote: > > Hello Allison, Jon, > > I understand the decision at last meeting was to issue a WG Last Call on > and make sure that, as part of the WGLC, > at least a couple of "RSVP Team" members write up their reviews. > > Could we go ahead with the LC? > > Could you help identify who from the "RSVP Team" can commit to written > reviews? > > That way we could work face to face in Vancouver to close potential > comments/issues from the review. > > Thank you > > Francois > > =================================== >> From draft minutes: > " >>> Allison said that she is willing to have a WGLC, but the WG >>> needs to have written reviews from the people that call >>> themselves the "RSVP team". >>> Any objections? No one voiced objections. >>> >>> Allson called for a hum: People supporting wglc at this time? >>> There was moderate support Allison declares enough support >>> to go ahead. The requirement will >>> be a least a couple of RSVP reviewers (from the RSVP team) >>> to write during WGLC. > " > > _______________________________________________ > 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 tsvwg-bounces@ietf.org Thu Oct 13 03:48:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPxpY-0000z5-N0; Thu, 13 Oct 2005 03:48:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPxpX-0000yw-5F for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 03:48:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00418 for ; Thu, 13 Oct 2005 03:48:44 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPxzn-0002Qt-7D for tsvwg@ietf.org; Thu, 13 Oct 2005 03:59:37 -0400 Received: from [194.95.73.130] (unknown [194.95.73.130]) by ilsa.franken.de (Postfix) with ESMTP id 2B30E245C5; Thu, 13 Oct 2005 09:48:22 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <20051012173213.D29834@openss7.org> References: <20050921162304.A29088@openss7.org> <28d6f7b73746b7bbe5b706a75222ce50@lurchi.franken.de> <20050922045114.B6756@openss7.org> <69d50fe7d87f21c6298f1f561145c166@lurchi.franken.de> <20050923033810.B18747@openss7.org> <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> <20051012173213.D29834@openss7.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <19f654a1cac7d6c70ff1794cc1d16d21@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Thu, 13 Oct 2005 09:47:28 +0200 To: bidulock@openss7.org X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Randall Stewart , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi Brian, see my comment in-line. Best regards Michael On Oct 13, 2005, at 1:32 Uhr, Brian F. G. Bidulock wrote: > Michael, > > On Wed, 12 Oct 2005, Michael Tuexen wrote: >> to do it. I would prefer the second, because either the receiver of >> an INIT supports >> SCTP and sends back an ABORT or does not support SCTP and sends back=20= >> an >> ICMP(protocol unreachable). So an ICMP(port unreachable) should never >> be generated. >> So I would like to make an explicit statement, that an SCTP >> implementation SHOULD >> not process an ICMP(port unreachable). >> >> What do you and others think? > > Could not an ICMP(port unreachable) be generated by a middlebox or > firewall (i.e. port proxy). Any reason it can not generate an ABORT? Since it decided that the port is unreachable, it must have looked at the INIT. So it knows SCTP. > > --brian > > --=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 tsvwg-bounces@ietf.org Thu Oct 13 03:50:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPxrA-0001OR-As; Thu, 13 Oct 2005 03:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPxr8-0001OH-MC for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 03:50:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00499 for ; Thu, 13 Oct 2005 03:50:23 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPy1b-0002Uf-LY for tsvwg@ietf.org; Thu, 13 Oct 2005 04:01:16 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j9D7o96c014168; Thu, 13 Oct 2005 09:50:09 +0200 Received: from mhpahx2c.ww002.siemens.net (mhpahx2c.mch.sbs.de [139.25.165.55]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j9D7o9bw026100; Thu, 13 Oct 2005 09:50:09 +0200 Received: from MCHP7RCA.ww002.siemens.net ([139.25.131.170]) by mhpahx2c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Oct 2005 09:50:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Thu, 13 Oct 2005 09:50:07 +0200 Message-ID: <004BAE2F21E51946A3B56FD99A2BEC39275F8E@MCHP7RCA.ww002.siemens.net> Thread-Topic: Re: [Tsvwg] ICMP issue with SCTP IG Thread-Index: AcXPZTlb5RRmlNVNRJiFWtISt8WVCAAYf4XQ From: "Schruefer, Wolfgang" To: "Michael Tuexen" , "Randall Stewart" X-OriginalArrivalTime: 13 Oct 2005 07:50:08.0773 (UTC) FILETIME=[BB9A6B50:01C5CFCA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Content-Transfer-Encoding: quoted-printable Cc: bidulock@openss7.org, tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael, I agree to all of your proposals. But additionally for a full hormonisation we should change also the link = to the appendix:=20 Old suggestion: 11.5 Protection of non-SCTP capable hosts. To provide non-SCTP capable host with the same level of protection=20 against attacks as SCTP capable ones all SCTP stacks MUST implement=20 the ICMP handling described in Appendix C. New suggestion (I also removed here this single 'attack-protection' = reason for ICMP-handling, because I think it is here unnecessary and = implies for readers that there is a concrete risk): 11.5 Protection of non-SCTP capable hosts All SCTP stacks SHOULD implement the ICMP handling described in = Appendix C. Best regards Wolfgang =20 > -----Urspr=FCngliche Nachricht----- > Von: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 > Gesendet: Mittwoch, 12. Oktober 2005 21:43 > An: Randall Stewart > Cc: tsvwg@ietf.org; Vlad Yasevich; Schruefer, Wolfgang;=20 > bidulock@openss7.org; Kacheong Poon; Scott Bradner; Coene, Lode > Betreff: Re: [Tsvwg] ICMP issue with SCTP IG >=20 > Randy, >=20 > in general I like the text you submitted. But I think it=20 > might be good to have the SCTP procedure in tune with the=20 > ones described in RFC 1122 (Host Requirements). >=20 > Section 3.2.2.1 of RFC 1122 states > A host SHOULD generate Destination Unreachable=20 > messages with > code: >=20 > 2 (Protocol Unreachable), when the designated=20 > transport > protocol is not supported; >=20 > A Destination Unreachable message that is=20 > received MUST be > reported to the transport layer. The transport=20 > layer SHOULD > use the information appropriately; for example,=20 > see Sections > 4.1.3.3, 4.2.3.9, and 4.2.4 below. >=20 > and section 4.2.3.9 states (for TCP) >=20 > o Destination Unreachable -- codes 2-4 >=20 > These are hard error conditions, so TCP SHOULD abort > the connection. >=20 > So I think to harmonize the future SCTP RFC with RFC 1122, we=20 > should change >=20 > ICMP9) If the ICMP code is an "Unrecognized next header type > encountered" or a "Protocol Unreachable" then the message > MUST be treated as an abort with the T bit set, checking > the Verification Tag in the ICMP message for validation. >=20 > to >=20 > ICMP9) If the ICMP code is an "Unrecognized next header type > encountered" or a "Protocol Unreachable" then the message > SHOULD be treated as an abort with the T bit set, checking > the Verification Tag in the ICMP message for validation. >=20 > Furthermore RFC 1122 states in section 3.2.2.1 >=20 > A transport protocol > that has its own mechanism for notifying the=20 > sender that a > port is unreachable (e.g., TCP, which sends RST segments) > MUST nevertheless accept an ICMP Port Unreachable for the > same purpose. >=20 > This covers SCTP too. So we should either add this rule to=20 > the ICMP processing rules or make an Implementation Note that=20 > we do not require an SCTP implementation to do it. I would=20 > prefer the second, because either the receiver of an INIT=20 > supports SCTP and sends back an ABORT or does not support=20 > SCTP and sends back an ICMP(protocol unreachable). So an=20 > ICMP(port unreachable) should never be generated. > So I would like to make an explicit statement, that an SCTP=20 > implementation SHOULD not process an ICMP(port unreachable). >=20 > What do you and others think? >=20 > Best regards > Michael >=20 >=20 > On Oct 7, 2005, at 7:00 PM, Randall Stewart wrote: >=20 > > All: > > > > In an attempt to draw this discussion and all the points we have=20 > > discussed to a close here is the text I am proposing we add to the=20 > > I-G. This I think covers all of our issues... > > > > Our new section 11.5 now looks as follows: > > > > ********************************************************* > > --------- > > New text > > --------- > > > > 11.5 Protection of non-SCTP capable hosts. > > > > To provide non-SCTP capable host with the same level of protection=20 > > against attacks as SCTP capable ones all SCTP stacks MUST implement=20 > > the ICMP handling described in Appendix C. > > > > When an SCTP stack receives a packet containing multiple control or=20 > > DATA chunks and the processing of the packet requires the=20 > sending of=20 > > multiple chunks in response, the sender of the response=20 > chunk('s) MUST=20 > > NOT send more than one packet. If bundling is supported multiple=20 > > response chunks that fit into a single packet MAY be=20 > bundled together=20 > > into one single response packet. If bundling is not=20 > supported then the=20 > > sender MUST NOT send more than one response chunk and MUST=20 > discard all=20 > > other responses. Note that this rule does NOT apply to a SACK chunk=20 > > since a SACK chunk is, in itself, a response to DATA and a=20 > SACK does=20 > > not require a response of more DATA. > > > > An SCTP implementation SHOULD abort the association if it=20 > receives a=20 > > SACK acknowledging a TSN which has not been sent. > > > > An SCTP implementation that receives an INIT that would require a=20 > > large packet in response, due to the inclusion of multiple ERROR=20 > > parameters, MAY (at its discrection) elect to omit some or=20 > all of the=20 > > ERROR parameters to reduce the size of the INIT-ACK. Due to a=20 > > combination of the size of the COOKIE parameter and the number of=20 > > addresses a receiver of an INIT may be indicating to a peer, it is=20 > > always possible that the INIT-ACK will be larger than the original=20 > > INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as=20 > > small as possible to reduce the possibility of byte amplification=20 > > attacks. > > > > ************************************************************* > > The ICMP section that goes with it looks as follows: > > ************************************************************* > > --------- > > New text: (Appendix C) > > --------- > > > > Appendix C ICMP Handling > > > > Whenever an ICMP message is received by an SCTP endpoint=20 > the following=20 > > procedures MUST be followed to assure proper utilization of the=20 > > information being provided by layer 3. > > > > ICMP1) Ignore all ICMPv4 messages where the type field is > > not set to "Destination Unreachable". > > > > ICMP2) Ignore all ICMPv6 messages where the type field is > > not "Destination Unreachable, "Parameter Problem" or > > "Packet Too Big". > > > > ICMP3) Ignore any ICMPv4 messages where the code does not > > indicate "Protocol Unreachable" or "Fragmentation Needed". > > > > ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if > > the code is not "Unrecognized next header type encountered". > > > > ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the > > association which sent the message that ICMP is=20 > responding to. > > If the association cannot be found, ignore the ICMP message. > > > > ICMP6) Validate that the verification tag contained in the ICMP > > message matches the verification tag of the peer. > > If the verification tag is not 0 and does NOT match, > > discard the ICMP message. If it is 0 and the ICMP message=20 > > contains > > enough bytes to verify that the chunk type is an INIT chunk > > and that the initiate tag matches the tag of the=20 > peer continue > > with ICMP7. If the ICMP message is too short, the chunk type > > or the initiate tag does not match, silently discard the=20 > > packet. > > > > ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 > > "Fragmentation Needed" process this information as=20 > defined for > > PATH MTU discovery. > > > > ICMP8) If the ICMP code is a "Unrecognized next header type > > encountered" or a "Protocol Unreachable" treat this message > > as an abort with the T bit set if it does not contain an > > INIT chunk. If it does contain an INIT chunk and the=20 > > association > > is in COOKIE-WAIT state, handle the ICMP message=20 > like an ABORT. > > > > ICMP9) If the ICMP code is an "Unrecognized next header type > > encountered" or a "Protocol Unreachable" then the message > > MUST be treated as an abort with the T bit set, checking > > the Verification Tag in the ICMP message for validation. > > > > ICMP10)If the ICMPv6 code is "Destination Unreachable" the > > implementation MAY mark the destination into the unreachable > > state or alternatively increment the path error counter. > > > >=20 > ********************************************************************** > > *** > > The path verification procedure end up as follows: > >=20 > ********************************************************************** > > ** > > --------- > > New text: (Section 5.4) > > --------- > > 5.4 Path Verification > > > > During association estabilishment the two peers exchange a list of=20 > > addresses. In the predominant case these lists accurately represent=20 > > the addresses owned by each peer. However there exists the=20 > possibility=20 > > that a mis-behaving peer may supply addresses that it does=20 > not own. To=20 > > prevent this the following rules are applied to all=20 > addresses of the=20 > > new association: > > > > 1) Any address passed to the sender of the INIT by its > > upper layer is automatically considered to be CONFIRMED. > > > > 2) For the receiver of the COOKIE-ECHO the only CONFIRMED > > address is the one that the INIT-ACK was sent to. > > > > 3) All other addresses not covered by rules 1 and 2 are considered > > UNCONFIRMED and are subject to probing for verification. > > > > To probe an address for verification, an endpoint will send=20 > > HEARTBEAT's including a 64 bit random nonce and a path=20 > indicator (to=20 > > identify the address that the HEARTBEAT is sent to) within the=20 > > HEARTBEAT parameter. > > > > Upon reception of the HEARTBEAT-ACK a verification is made that the=20 > > nonce included in the HEARTBEAT parameter is the one sent to the=20 > > address indicated inside the HEARTBEAT parameter. When this match=20 > > occurs, the address that the original HEARTBEAT was sent to is now=20 > > considered CONFIRMED and available for normal data transfer. > > > > These probing proceedures are started when an association=20 > moves to the=20 > > ESTABLISHED state and are ended when all paths are confirmed. > > > > Each RTO a probe may be sent on an active UNCONFIRMED path in an=20 > > attempt to move it to to the CONFIRMED state. > > If during this probing the path becomes inactive this rate=20 > is lowered=20 > > to the normal HEARTBEAT rate. At the expiration of the RTO=20 > timer the=20 > > error counter of any path that was probed but not CONFIRMED is=20 > > incremented by one and subjected to path failure detection=20 > defined in=20 > > section 8.2. When probing UNCONFIRMED addresses, however, the=20 > > association overall error count is NOT incremented. > > > > The number of HEARTBEATS sent at each RTO SHOULD be limited by the=20 > > HB.Max.Burst parameter. It is an implementation decision as=20 > to how to=20 > > distribute HEARTBEATS to the peers addresses for path verification. > > > > Whenever a path is confirmed an indication MAY be given to to the=20 > > upper layer. > > > > An endpoint MUST NOT send any chunks to an UNCONFIRMED address with=20 > > the following exceptions: > > > > - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED > > address. > > > > - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address. > > > > - A COOKIE-ACK MAY be sent to an UNCONFIRMED address but > > it MUST be bundled with a HEARTBEAT including a nonce. > > An implementation that does NOT support bundling MUST > > NOT send a COOKIE-ACK to an UNCONFIRMED address. > > > > - A COOKE-ECHO MAY be sent to an UNCONFIRMED address but > > it MUST be bundled with a HEARTBEAT including a nonce > > and the packet MUST NOT exceed the path MTU. If the > > implementation does NOT support bundling or the bundled > > COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed > > the path MTU, then the implemenation MUST NOT send > > a COOKIE-ECHO to an UNCONFIRMED address. > > > > ************************************************************* > > With the corresponding parameter defaults as follows: > > ************************************************************* > > The following protocol parameters are RECOMMENDED: > > > > RTO.Initial - 3 seconds > > RTO.Min - 1 second > > RTO.Max - 60 seconds > > Max.Burst - 4 > > RTO.Alpha - 1/8 > > RTO.Beta - 1/4 > > Valid.Cookie.Life - 60 seconds > > Association.Max.Retrans - 10 attempts > > Path.Max.Retrans - 5 attempts (per destination address) > > Max.Init.Retransmits - 8 attempts > > HB.Interval - 30 seconds > > HB.Max.Burst - 1 > > > > **************************************************************** > > > > > > I think this covers all that we had talked about... the byte=20 > > amplification of INIT-ACK is mentioned/noted and I think we should=20 > > move on... Implementations can minimize there INIT-ACK's as=20 > they deem=20 > > appropriate and are now allowed to omit errors... > > > > Note, commens and suggested changes, as always, are most welcome :-D > > > > R > > > > -- > > Randall Stewart > > 803-345-0369 815-342-5222(cell) > > > > > > >=20 >=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 13 04:12:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPyCr-0007Ub-3Q; Thu, 13 Oct 2005 04:12:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPyCp-0007UA-2P for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 04:12:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01587 for ; Thu, 13 Oct 2005 04:12:47 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[z4kcLy4VtdHhPUsHiq0rMRQlMCODq8RB]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPyNH-0003F5-O1 for tsvwg@ietf.org; Thu, 13 Oct 2005 04:23:41 -0400 Received: from ns.pigworks.openss7.net (IDENT:RQi9al9ueAwuV+aMdroOsAfDZe0qYfzX@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j9D8BEc23278; Thu, 13 Oct 2005 02:11:14 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j9D8BDL08169; Thu, 13 Oct 2005 02:11:13 -0600 Date: Thu, 13 Oct 2005 02:11:13 -0600 From: "Brian F. G. Bidulock" To: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051013021112.A8132@openss7.org> References: <20050922045114.B6756@openss7.org> <69d50fe7d87f21c6298f1f561145c166@lurchi.franken.de> <20050923033810.B18747@openss7.org> <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> <20051012173213.D29834@openss7.org> <19f654a1cac7d6c70ff1794cc1d16d21@lurchi.franken.de> 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: <19f654a1cac7d6c70ff1794cc1d16d21@lurchi.franken.de>; from Michael.Tuexen@lurchi.franken.de on Thu, Oct 13, 2005 at 09:47:28AM +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 j9D8BEc23278 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Randall Stewart , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael, On Thu, 13 Oct 2005, Michael Tuexen wrote: > >> to do it. I would prefer the second, because either the receiver of > >> an INIT supports > >> SCTP and sends back an ABORT or does not support SCTP and sends back= =20 > >> an > >> ICMP(protocol unreachable). So an ICMP(port unreachable) should neve= r > >> be generated. > >> So I would like to make an explicit statement, that an SCTP > >> implementation SHOULD > >> not process an ICMP(port unreachable). > >> > >> What do you and others think? > > > > Could not an ICMP(port unreachable) be generated by a middlebox or > > firewall (i.e. port proxy). > Any reason it can not generate an ABORT? Since it decided that > the port is unreachable, it must have looked at the INIT. So it > knows SCTP. Well, we allowed ABORTs to be suppressed, didn't we? --brian --=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 tsvwg-bounces@ietf.org Thu Oct 13 04:55:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPysX-0001g2-MU; Thu, 13 Oct 2005 04:55:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPysV-0001Zo-8u for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 04:55:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03715 for ; Thu, 13 Oct 2005 04:55:51 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[3fP3iXoBC/F9cLHRmwyCdA1oE98gNUUb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPz2x-0004T3-SR for tsvwg@ietf.org; Thu, 13 Oct 2005 05:06:45 -0400 Received: from ns.pigworks.openss7.net (IDENT:GtuDAgL42t0bWBADfjUkgks8/4q8RIwP@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j9D8Hcc23349; Thu, 13 Oct 2005 02:17:38 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j9D8HbP08207; Thu, 13 Oct 2005 02:17:37 -0600 Date: Thu, 13 Oct 2005 02:17:37 -0600 From: "Brian F. G. Bidulock" To: "Schruefer, Wolfgang" Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051013021737.B8132@openss7.org> References: <004BAE2F21E51946A3B56FD99A2BEC39275F8E@MCHP7RCA.ww002.siemens.net> 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: <004BAE2F21E51946A3B56FD99A2BEC39275F8E@MCHP7RCA.ww002.siemens.net>; from wolfgang.schruefer@siemens.com on Thu, Oct 13, 2005 at 09:50:07AM +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 j9D8Hcc23349 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , Randall Stewart , Scott Bradner , Kacheong Poon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Wolfgang, I didn't really have problem with a MUST, just that the MUST cannot apply to all of the mention of discarding ICMP messages in Appendix C, because non-SCTP capable hosts are not protected by discarding ICMP messages. It is in the processing of the ICMP messages (aborting associations, marking destinations unusable) that non-SCTP capable hosts are protected, not in the discarding. If the MUST is limited to the specific behaviour that does protect non-SCTP capable hosts, I think that a MUST is called for instead of a SHOULD. --brian On Thu, 13 Oct 2005, Schruefer, Wolfgang wrote: > Michael, >=20 > I agree to all of your proposals. >=20 > But additionally for a full hormonisation we should change also the > link to the appendix:=20 >=20 > Old suggestion: >=20 > 11.5 Protection of non-SCTP capable hosts. >=20 > To provide non-SCTP capable host with the same level of protection=20 > against attacks as SCTP capable ones all SCTP stacks MUST implement= =20 > the ICMP handling described in Appendix C. >=20 > New suggestion (I also removed here this single 'attack-protection' > reason for ICMP-handling, because I think it is here unnecessary and > implies for readers that there is a concrete risk): >=20 > 11.5 Protection of non-SCTP capable hosts >=20 > All SCTP stacks SHOULD implement the ICMP handling described in App= endix C. >=20 > Best regards > Wolfgang > =20 --=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 tsvwg-bounces@ietf.org Thu Oct 13 11:18:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4qS-0003YZ-Iw; Thu, 13 Oct 2005 11:18:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4qQ-0003YO-ER for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 11:18:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23281 for ; Thu, 13 Oct 2005 11:18:06 -0400 (EDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ50x-0006VT-Q1 for tsvwg@ietf.org; Thu, 13 Oct 2005 11:29:04 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9DFG8nQ002080 for ; Thu, 13 Oct 2005 18:16:10 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Oct 2005 18:18:04 +0300 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Oct 2005 18:18:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Oct 2005 18:18:02 +0300 Message-ID: <921445D056CC0E4FAFA3F0566793E827013792D7@esebe104.NOE.Nokia.com> Thread-Topic: Bytes used for calculation of the HMAC in SCTP Thread-Index: AcW9MtbmTjmImvOyRvGSUhPcChNpkQS1e79Q To: X-OriginalArrivalTime: 13 Oct 2005 15:18:04.0053 (UTC) FILETIME=[4E84B450:01C5D009] X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] Bytes used for calculation of the HMAC in SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi all! I guess I know the answer but I think it is not clear enough in the = draft. It is about the padding bytes of the chunks covered by the AUTH = chunk. I suppose that the padding bytes of all the chunks but the last = one are included in the calculation of the HMAC, but I would say that = nothing regarding that is stated in the draft. Thanks! BR Iv=E1n Arias Rodr=EDguez=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 13 13:27:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6rb-0002Cg-AG; Thu, 13 Oct 2005 13:27:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6rX-0002BT-L7 for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 13:27:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00058 for ; Thu, 13 Oct 2005 13:27:22 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ723-0001YT-1o for tsvwg@ietf.org; Thu, 13 Oct 2005 13:38:21 -0400 Received: from [10.226.133.42] (ip-80-226-239-90.vodafone-net.de [80.226.239.90]) by ilsa.franken.de (Postfix) with ESMTP id 68F93245D0; Thu, 13 Oct 2005 19:27:16 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <004BAE2F21E51946A3B56FD99A2BEC39275F8E@MCHP7RCA.ww002.siemens.net> References: <004BAE2F21E51946A3B56FD99A2BEC39275F8E@MCHP7RCA.ww002.siemens.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <677BBC55-115C-4848-B8D3-09F13EC3EB7E@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Thu, 13 Oct 2005 19:26:59 +0200 To: "Schruefer, Wolfgang" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 17589c7043b24a47064a4b7516f59671 Content-Transfer-Encoding: quoted-printable Cc: bidulock@openss7.org, tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Randall Stewart , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi Wolfgang, I disagree with your proposed change. The intention of my text is to =20 harmonize the SCTP IG and RFC1122. RFC1122 states that: A Destination Unreachable message that is received MUST be reported to the transport layer. So changing the MUST to SHOULD as you suggest does NOT harmonize it. Best regards Michael On Oct 13, 2005, at 9:50 AM, Schruefer, Wolfgang wrote: > Michael, > > I agree to all of your proposals. > > But additionally for a full hormonisation we should change also the =20= > link to the appendix: > > Old suggestion: > > 11.5 Protection of non-SCTP capable hosts. > > To provide non-SCTP capable host with the same level of protection > against attacks as SCTP capable ones all SCTP stacks MUST =20 > implement > the ICMP handling described in Appendix C. > > New suggestion (I also removed here this single 'attack-protection' =20= > reason for ICMP-handling, because I think it is here unnecessary =20 > and implies for readers that there is a concrete risk): > > 11.5 Protection of non-SCTP capable hosts > > All SCTP stacks SHOULD implement the ICMP handling described in =20= > Appendix C. > > Best regards > Wolfgang > > > >> -----Urspr=FCngliche Nachricht----- >> Von: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >> Gesendet: Mittwoch, 12. Oktober 2005 21:43 >> An: Randall Stewart >> Cc: tsvwg@ietf.org; Vlad Yasevich; Schruefer, Wolfgang; >> bidulock@openss7.org; Kacheong Poon; Scott Bradner; Coene, Lode >> Betreff: Re: [Tsvwg] ICMP issue with SCTP IG >> >> Randy, >> >> in general I like the text you submitted. But I think it >> might be good to have the SCTP procedure in tune with the >> ones described in RFC 1122 (Host Requirements). >> >> Section 3.2.2.1 of RFC 1122 states >> A host SHOULD generate Destination Unreachable >> messages with >> code: >> >> 2 (Protocol Unreachable), when the designated >> transport >> protocol is not supported; >> >> A Destination Unreachable message that is >> received MUST be >> reported to the transport layer. The transport >> layer SHOULD >> use the information appropriately; for example, >> see Sections >> 4.1.3.3, 4.2.3.9, and 4.2.4 below. >> >> and section 4.2.3.9 states (for TCP) >> >> o Destination Unreachable -- codes 2-4 >> >> These are hard error conditions, so TCP SHOULD =20 >> abort >> the connection. >> >> So I think to harmonize the future SCTP RFC with RFC 1122, we >> should change >> >> ICMP9) If the ICMP code is an "Unrecognized next header type >> encountered" or a "Protocol Unreachable" then the message >> MUST be treated as an abort with the T bit set, checking >> the Verification Tag in the ICMP message for validation. >> >> to >> >> ICMP9) If the ICMP code is an "Unrecognized next header type >> encountered" or a "Protocol Unreachable" then the message >> SHOULD be treated as an abort with the T bit set, checking >> the Verification Tag in the ICMP message for validation. >> >> Furthermore RFC 1122 states in section 3.2.2.1 >> >> A transport protocol >> that has its own mechanism for notifying the >> sender that a >> port is unreachable (e.g., TCP, which sends RST =20 >> segments) >> MUST nevertheless accept an ICMP Port Unreachable for =20= >> the >> same purpose. >> >> This covers SCTP too. So we should either add this rule to >> the ICMP processing rules or make an Implementation Note that >> we do not require an SCTP implementation to do it. I would >> prefer the second, because either the receiver of an INIT >> supports SCTP and sends back an ABORT or does not support >> SCTP and sends back an ICMP(protocol unreachable). So an >> ICMP(port unreachable) should never be generated. >> So I would like to make an explicit statement, that an SCTP >> implementation SHOULD not process an ICMP(port unreachable). >> >> What do you and others think? >> >> Best regards >> Michael >> >> >> On Oct 7, 2005, at 7:00 PM, Randall Stewart wrote: >> >> >>> All: >>> >>> In an attempt to draw this discussion and all the points we have >>> discussed to a close here is the text I am proposing we add to the >>> I-G. This I think covers all of our issues... >>> >>> Our new section 11.5 now looks as follows: >>> >>> ********************************************************* >>> --------- >>> New text >>> --------- >>> >>> 11.5 Protection of non-SCTP capable hosts. >>> >>> To provide non-SCTP capable host with the same level of protection >>> against attacks as SCTP capable ones all SCTP stacks MUST implement >>> the ICMP handling described in Appendix C. >>> >>> When an SCTP stack receives a packet containing multiple control or >>> DATA chunks and the processing of the packet requires the >>> >> sending of >> >>> multiple chunks in response, the sender of the response >>> >> chunk('s) MUST >> >>> NOT send more than one packet. If bundling is supported multiple >>> response chunks that fit into a single packet MAY be >>> >> bundled together >> >>> into one single response packet. If bundling is not >>> >> supported then the >> >>> sender MUST NOT send more than one response chunk and MUST >>> >> discard all >> >>> other responses. Note that this rule does NOT apply to a SACK chunk >>> since a SACK chunk is, in itself, a response to DATA and a >>> >> SACK does >> >>> not require a response of more DATA. >>> >>> An SCTP implementation SHOULD abort the association if it >>> >> receives a >> >>> SACK acknowledging a TSN which has not been sent. >>> >>> An SCTP implementation that receives an INIT that would require a >>> large packet in response, due to the inclusion of multiple ERROR >>> parameters, MAY (at its discrection) elect to omit some or >>> >> all of the >> >>> ERROR parameters to reduce the size of the INIT-ACK. Due to a >>> combination of the size of the COOKIE parameter and the number of >>> addresses a receiver of an INIT may be indicating to a peer, it is >>> always possible that the INIT-ACK will be larger than the original >>> INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as >>> small as possible to reduce the possibility of byte amplification >>> attacks. >>> >>> ************************************************************* >>> The ICMP section that goes with it looks as follows: >>> ************************************************************* >>> --------- >>> New text: (Appendix C) >>> --------- >>> >>> Appendix C ICMP Handling >>> >>> Whenever an ICMP message is received by an SCTP endpoint >>> >> the following >> >>> procedures MUST be followed to assure proper utilization of the >>> information being provided by layer 3. >>> >>> ICMP1) Ignore all ICMPv4 messages where the type field is >>> not set to "Destination Unreachable". >>> >>> ICMP2) Ignore all ICMPv6 messages where the type field is >>> not "Destination Unreachable, "Parameter Problem" or >>> "Packet Too Big". >>> >>> ICMP3) Ignore any ICMPv4 messages where the code does not >>> indicate "Protocol Unreachable" or "Fragmentation Needed". >>> >>> ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if >>> the code is not "Unrecognized next header type encountered". >>> >>> ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the >>> association which sent the message that ICMP is >>> >> responding to. >> >>> If the association cannot be found, ignore the ICMP message. >>> >>> ICMP6) Validate that the verification tag contained in the ICMP >>> message matches the verification tag of the peer. >>> If the verification tag is not 0 and does NOT match, >>> discard the ICMP message. If it is 0 and the ICMP message >>> contains >>> enough bytes to verify that the chunk type is an INIT chunk >>> and that the initiate tag matches the tag of the >>> >> peer continue >> >>> with ICMP7. If the ICMP message is too short, the chunk type >>> or the initiate tag does not match, silently discard the >>> packet. >>> >>> ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 >>> "Fragmentation Needed" process this information as >>> >> defined for >> >>> PATH MTU discovery. >>> >>> ICMP8) If the ICMP code is a "Unrecognized next header type >>> encountered" or a "Protocol Unreachable" treat this message >>> as an abort with the T bit set if it does not contain an >>> INIT chunk. If it does contain an INIT chunk and the >>> association >>> is in COOKIE-WAIT state, handle the ICMP message >>> >> like an ABORT. >> >>> >>> ICMP9) If the ICMP code is an "Unrecognized next header type >>> encountered" or a "Protocol Unreachable" then the message >>> MUST be treated as an abort with the T bit set, checking >>> the Verification Tag in the ICMP message for validation. >>> >>> ICMP10)If the ICMPv6 code is "Destination Unreachable" the >>> implementation MAY mark the destination into the unreachable >>> state or alternatively increment the path error counter. >>> >>> >>> >> *********************************************************************=20= >> * >> >>> *** >>> The path verification procedure end up as follows: >>> >>> >> *********************************************************************=20= >> * >> >>> ** >>> --------- >>> New text: (Section 5.4) >>> --------- >>> 5.4 Path Verification >>> >>> During association estabilishment the two peers exchange a list of >>> addresses. In the predominant case these lists accurately represent >>> the addresses owned by each peer. However there exists the >>> >> possibility >> >>> that a mis-behaving peer may supply addresses that it does >>> >> not own. To >> >>> prevent this the following rules are applied to all >>> >> addresses of the >> >>> new association: >>> >>> 1) Any address passed to the sender of the INIT by its >>> upper layer is automatically considered to be CONFIRMED. >>> >>> 2) For the receiver of the COOKIE-ECHO the only CONFIRMED >>> address is the one that the INIT-ACK was sent to. >>> >>> 3) All other addresses not covered by rules 1 and 2 are considered >>> UNCONFIRMED and are subject to probing for verification. >>> >>> To probe an address for verification, an endpoint will send >>> HEARTBEAT's including a 64 bit random nonce and a path >>> >> indicator (to >> >>> identify the address that the HEARTBEAT is sent to) within the >>> HEARTBEAT parameter. >>> >>> Upon reception of the HEARTBEAT-ACK a verification is made that the >>> nonce included in the HEARTBEAT parameter is the one sent to the >>> address indicated inside the HEARTBEAT parameter. When this match >>> occurs, the address that the original HEARTBEAT was sent to is now >>> considered CONFIRMED and available for normal data transfer. >>> >>> These probing proceedures are started when an association >>> >> moves to the >> >>> ESTABLISHED state and are ended when all paths are confirmed. >>> >>> Each RTO a probe may be sent on an active UNCONFIRMED path in an >>> attempt to move it to to the CONFIRMED state. >>> If during this probing the path becomes inactive this rate >>> >> is lowered >> >>> to the normal HEARTBEAT rate. At the expiration of the RTO >>> >> timer the >> >>> error counter of any path that was probed but not CONFIRMED is >>> incremented by one and subjected to path failure detection >>> >> defined in >> >>> section 8.2. When probing UNCONFIRMED addresses, however, the >>> association overall error count is NOT incremented. >>> >>> The number of HEARTBEATS sent at each RTO SHOULD be limited by the >>> HB.Max.Burst parameter. It is an implementation decision as >>> >> to how to >> >>> distribute HEARTBEATS to the peers addresses for path verification. >>> >>> Whenever a path is confirmed an indication MAY be given to to the >>> upper layer. >>> >>> An endpoint MUST NOT send any chunks to an UNCONFIRMED address with >>> the following exceptions: >>> >>> - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED >>> address. >>> >>> - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address. >>> >>> - A COOKIE-ACK MAY be sent to an UNCONFIRMED address but >>> it MUST be bundled with a HEARTBEAT including a nonce. >>> An implementation that does NOT support bundling MUST >>> NOT send a COOKIE-ACK to an UNCONFIRMED address. >>> >>> - A COOKE-ECHO MAY be sent to an UNCONFIRMED address but >>> it MUST be bundled with a HEARTBEAT including a nonce >>> and the packet MUST NOT exceed the path MTU. If the >>> implementation does NOT support bundling or the bundled >>> COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed >>> the path MTU, then the implemenation MUST NOT send >>> a COOKIE-ECHO to an UNCONFIRMED address. >>> >>> ************************************************************* >>> With the corresponding parameter defaults as follows: >>> ************************************************************* >>> The following protocol parameters are RECOMMENDED: >>> >>> RTO.Initial - 3 seconds >>> RTO.Min - 1 second >>> RTO.Max - 60 seconds >>> Max.Burst - 4 >>> RTO.Alpha - 1/8 >>> RTO.Beta - 1/4 >>> Valid.Cookie.Life - 60 seconds >>> Association.Max.Retrans - 10 attempts >>> Path.Max.Retrans - 5 attempts (per destination address) >>> Max.Init.Retransmits - 8 attempts >>> HB.Interval - 30 seconds >>> HB.Max.Burst - 1 >>> >>> **************************************************************** >>> >>> >>> I think this covers all that we had talked about... the byte >>> amplification of INIT-ACK is mentioned/noted and I think we should >>> move on... Implementations can minimize there INIT-ACK's as >>> >> they deem >> >>> appropriate and are now allowed to omit errors... >>> >>> Note, commens and suggested changes, as always, are most welcome :-D >>> >>> R >>> >>> -- >>> Randall Stewart >>> 803-345-0369 815-342-5222(cell) >>> >>> >>> >>> >> >> >> > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 13 13:31:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6vU-0003ko-Ga; Thu, 13 Oct 2005 13:31:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6vT-0003kj-Ho for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 13:31:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00451 for ; Thu, 13 Oct 2005 13:31:27 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ760-0001iY-UK for tsvwg@ietf.org; Thu, 13 Oct 2005 13:42:26 -0400 Received: from [10.226.133.42] (ip-80-226-239-90.vodafone-net.de [80.226.239.90]) by ilsa.franken.de (Postfix) with ESMTP id 061E1245DB; Thu, 13 Oct 2005 19:31:24 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <20051013021112.A8132@openss7.org> References: <20050922045114.B6756@openss7.org> <69d50fe7d87f21c6298f1f561145c166@lurchi.franken.de> <20050923033810.B18747@openss7.org> <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> <20051012173213.D29834@openss7.org> <19f654a1cac7d6c70ff1794cc1d16d21@lurchi.franken.de> <20051013021112.A8132@openss7.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <84B66FE5-5CF2-4E4E-B5E0-A13F93CF7F4D@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Thu, 13 Oct 2005 19:31:13 +0200 To: bidulock@openss7.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Randall Stewart , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Brian, see my comment in-line. Best regards Michael On Oct 13, 2005, at 10:11 AM, Brian F. G. Bidulock wrote: > Michael, > > On Thu, 13 Oct 2005, Michael Tuexen wrote: > > >>>> to do it. I would prefer the second, because either the receiver of >>>> an INIT supports >>>> SCTP and sends back an ABORT or does not support SCTP and sends =20 >>>> back >>>> an >>>> ICMP(protocol unreachable). So an ICMP(port unreachable) should =20 >>>> never >>>> be generated. >>>> So I would like to make an explicit statement, that an SCTP >>>> implementation SHOULD >>>> not process an ICMP(port unreachable). >>>> >>>> What do you and others think? >>>> >>> >>> Could not an ICMP(port unreachable) be generated by a middlebox or >>> firewall (i.e. port proxy). >>> >> Any reason it can not generate an ABORT? Since it decided that >> the port is unreachable, it must have looked at the INIT. So it >> knows SCTP. >> > > Well, we allowed ABORTs to be suppressed, didn't we? Yes. And I think if you do not want to see ABORTs you do not want to see ICMP(port unreachable). If an endpoint/middlebox want to say that a particular port number is not reachable it should use ABORT instead of ICMP(port unreachable). I think the ICMP(port unreachable) for TCP is there for historic =20 reasons, so it does not apply for SCTP. But possibly someone with better =20 knowledge can jump in here and tell us why an TCP implementation has to support ICMP(port unreachable). If it has a reason in addition to the =20 historic one, it may also apply to SCTP and we have to adopt the text accordingly. > > --brian > > --=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 tsvwg-bounces@ietf.org Thu Oct 13 13:42:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ762-000682-RO; Thu, 13 Oct 2005 13:42:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ761-00067u-TI for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 13:42:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01230 for ; Thu, 13 Oct 2005 13:42:21 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ7Ga-00023N-G9 for tsvwg@ietf.org; Thu, 13 Oct 2005 13:53:20 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2005 19:42:16 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9DHgCHH017826; Thu, 13 Oct 2005 19:42:13 +0200 (MEST) Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Oct 2005 19:42:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Oct 2005 19:42:07 +0200 Message-ID: Thread-Topic: The mail we discussed Thread-Index: AcXQAxWGqHp3eaHERdKW7S4NnIBk2QAGHidQ From: "Francois Le Faucheur \(flefauch\)" To: X-OriginalArrivalTime: 13 Oct 2005 17:42:12.0859 (UTC) FILETIME=[719BC4B0:01C5D01D] X-Spam-Score: 0.8 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org Subject: [Tsvwg] RE: The mail we discussed X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hello Aaron, As per TSVWG final minutes (available from http://www3.ietf.org/proceedings/05aug/index.html) " Allison declares enough support to go ahead. The requirement will be a least a couple of RSVP reviewers (from the RSVP team) to write during WGLC. " So I believe the agreement was that the "RSVP team" members review would happen during the WGLC. Thanks Francois PS: For one of my other documents (draft-lefaucheur-rsvp-ipsec-01.txt) there was indeed a sort of "prerequisite" that some security experts review the doc before the WG can moce too far with that document. Perhaps this is where the confusion comes from. ________________________________ From: Aaron Falk =20 Date: October 13, 2005 12:06:45 AM EDT=20 To: "Francois Le Faucheur (flefauch)" , Allison Mankin , "Peterson, Jon" =20 Cc: gash@att.com, Davenport Michael , tsvwg@ietf.org, Christou Chris =20 Subject: Re: [Tsvwg] WG Last Call on draft-tsvwg-rsvp-dste-00.txt=20 =09 Francois-=20 My (admittedly vague) recollection is that the expert writeup was a pre-requisite to WGLC, not part of WGLC.=20 --aaron=20 --On October 12, 2005 5:04:18 PM +0200 "Francois Le Faucheur (flefauch)" wrote:=20 Hello Allison, Jon,=20 I understand the decision at last meeting was to issue a WG Last Call on=20 and make sure that, as part of the WGLC,=20 at least a couple of "RSVP Team" members write up their reviews.=20 Could we go ahead with the LC?=20 Could you help identify who from the "RSVP Team" can commit to written=20 reviews?=20 That way we could work face to face in Vancouver to close potential=20 comments/issues from the review.=20 Thank you=20 Francois=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 From draft minutes:=20 "=20 Allison said that she is willing to have a WGLC, but the WG=20 needs to have written reviews from the people that call=20 themselves the "RSVP team".=20 Any objections? No one voiced objections.=20 Allson called for a hum: People supporting wglc at this time?=20 There was moderate support Allison declares enough support=20 to go ahead. The requirement will=20 be a least a couple of RSVP reviewers (from the RSVP team)=20 to write during WGLC.=20 "=20 _______________________________________________=20 tsvwg mailing list=20 tsvwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/tsvwg=20 _______________________________________________=20 tsvwg mailing list=20 tsvwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/tsvwg=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 13 13:45:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ78Z-0006iA-Cm; Thu, 13 Oct 2005 13:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ78X-0006h2-E9 for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 13:45:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01356 for ; Thu, 13 Oct 2005 13:44:56 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ7J6-00026i-5E for tsvwg@ietf.org; Thu, 13 Oct 2005 13:55:56 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2005 19:44:53 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9DHinHH018172; Thu, 13 Oct 2005 19:44:49 +0200 (MEST) Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Oct 2005 19:44:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Tsvwg] WG Last Call on draft-tsvwg-rsvp-dste-00.txt Date: Thu, 13 Oct 2005 19:44:44 +0200 Message-ID: Thread-Topic: Re: [Tsvwg] WG Last Call on draft-tsvwg-rsvp-dste-00.txt Thread-Index: AcXQHcvus8+OyxC1SVqWMn/FnyOTYg== From: "Francois Le Faucheur \(flefauch\)" To: X-OriginalArrivalTime: 13 Oct 2005 17:44:49.0481 (UTC) FILETIME=[CEF66390:01C5D01D] X-Spam-Score: 0.8 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org RESENT WITH PROPER SUBJECT LINE Apologies for the duplicate =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Hello Aaron, As per TSVWG final minutes (available from http://www3.ietf.org/proceedings/05aug/index.html) " Allison declares enough support to go ahead. The requirement will be a least a couple of RSVP reviewers (from the RSVP team) to write during WGLC. " So I believe the agreement was that the "RSVP team" members review would happen during the WGLC. Thanks Francois PS: For one of my other documents (draft-lefaucheur-rsvp-ipsec-01.txt) there was indeed a sort of "prerequisite" that some security experts review the doc before the WG can moce too far with that document. Perhaps this is where the confusion comes from. ________________________________ From: Aaron Falk =20 Date: October 13, 2005 12:06:45 AM EDT=20 To: "Francois Le Faucheur (flefauch)" , Allison Mankin , "Peterson, Jon" =20 Cc: gash@att.com, Davenport Michael , tsvwg@ietf.org, Christou Chris =20 Subject: Re: [Tsvwg] WG Last Call on draft-tsvwg-rsvp-dste-00.txt=20 =09 Francois-=20 My (admittedly vague) recollection is that the expert writeup was a pre-requisite to WGLC, not part of WGLC.=20 --aaron=20 --On October 12, 2005 5:04:18 PM +0200 "Francois Le Faucheur (flefauch)" wrote:=20 Hello Allison, Jon,=20 I understand the decision at last meeting was to issue a WG Last Call on=20 and make sure that, as part of the WGLC,=20 at least a couple of "RSVP Team" members write up their reviews.=20 Could we go ahead with the LC?=20 Could you help identify who from the "RSVP Team" can commit to written=20 reviews?=20 That way we could work face to face in Vancouver to close potential=20 comments/issues from the review.=20 Thank you=20 Francois=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 From draft minutes:=20 "=20 Allison said that she is willing to have a WGLC, but the WG=20 needs to have written reviews from the people that call=20 themselves the "RSVP team".=20 Any objections? No one voiced objections.=20 Allson called for a hum: People supporting wglc at this time?=20 There was moderate support Allison declares enough support=20 to go ahead. The requirement will=20 be a least a couple of RSVP reviewers (from the RSVP team)=20 to write during WGLC.=20 "=20 _______________________________________________=20 tsvwg mailing list=20 tsvwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/tsvwg=20 _______________________________________________=20 tsvwg mailing list=20 tsvwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/tsvwg=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 13 14:06:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7TE-0005aF-BU; Thu, 13 Oct 2005 14:06:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7TC-0005X0-As for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 14:06:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02908 for ; Thu, 13 Oct 2005 14:06:17 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[SVbjo4RRKSt0HG8Cmw6ftIhTIXkRNBjj]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ7dk-0002nv-6H for tsvwg@ietf.org; Thu, 13 Oct 2005 14:17:17 -0400 Received: from ns.pigworks.openss7.net (IDENT:SyEGo07r2uuiXwLSHYIIvuxPMjT1gs3U@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j9DI5mc02963; Thu, 13 Oct 2005 12:05:48 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j9DI5lQ14305; Thu, 13 Oct 2005 12:05:47 -0600 Date: Thu, 13 Oct 2005 12:05:47 -0600 From: "Brian F. G. Bidulock" To: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051013120547.L13555@openss7.org> References: <20050923033810.B18747@openss7.org> <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> <20051012173213.D29834@openss7.org> <19f654a1cac7d6c70ff1794cc1d16d21@lurchi.franken.de> <20051013021112.A8132@openss7.org> <84B66FE5-5CF2-4E4E-B5E0-A13F93CF7F4D@lurchi.franken.de> 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: <84B66FE5-5CF2-4E4E-B5E0-A13F93CF7F4D@lurchi.franken.de>; from Michael.Tuexen@lurchi.franken.de on Thu, Oct 13, 2005 at 07:31:13PM +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 j9DI5mc02963 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Randall Stewart , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael, On Thu, 13 Oct 2005, Michael Tuexen wrote: > >>> Could not an ICMP(port unreachable) be generated by a middlebox or > >>> firewall (i.e. port proxy). > >>> > >> Any reason it can not generate an ABORT? Since it decided that > >> the port is unreachable, it must have looked at the INIT. So it > >> knows SCTP. > >> > > > > Well, we allowed ABORTs to be suppressed, didn't we? > Yes. And I think if you do not want to see ABORTs you do not > want to see ICMP(port unreachable). Maybe, maybe not. But I don't think that they MUST be ignored. I think they MAY be ignored. >=20 > If an endpoint/middlebox want to say that a particular port number > is not reachable it should use ABORT instead of ICMP(port unreachable). I don't think the SCTP specification (transport) should place requirement= s on what the network layer should or should not send. --=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 tsvwg-bounces@ietf.org Thu Oct 13 17:03:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAEZ-0007dy-K3; Thu, 13 Oct 2005 17:03:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAEX-0007dq-P0 for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 17:03:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17146 for ; Thu, 13 Oct 2005 17:03:22 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQAP7-0000xG-6F for tsvwg@ietf.org; Thu, 13 Oct 2005 17:14:22 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j9DL35EV083355; Thu, 13 Oct 2005 17:03:14 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <434ECB6A.20100@stewart.chicago.il.us> Date: Thu, 13 Oct 2005 17:02:34 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Tsvwg] ICMP issue with SCTP IG References: <20050923033810.B18747@openss7.org> <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> <20051012173213.D29834@openss7.org> <19f654a1cac7d6c70ff1794cc1d16d21@lurchi.franken.de> <20051013021112.A8132@openss7.org> <84B66FE5-5CF2-4E4E-B5E0-A13F93CF7F4D@lurchi.franken.de> <20051013120547.L13555@openss7.org> In-Reply-To: <20051013120547.L13555@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Brian F. G. Bidulock wrote: >>If an endpoint/middlebox want to say that a particular port number >>is not reachable it should use ABORT instead of ICMP(port unreachable). > > > I don't think the SCTP specification (transport) should place requirements > on what the network layer should or should not send. > I think the router requirments document already does this.. and I don't remember anything in the I-G that requires a middlebox to send anything.. if there is please point it out to me since we should get rid of it.. R > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 13 18:02:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB9V-0000Ur-4Q; Thu, 13 Oct 2005 18:02:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB9U-0000Uj-6K for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 18:02:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20538 for ; Thu, 13 Oct 2005 18:02:12 -0400 (EDT) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBK4-0002ax-1w for tsvwg@ietf.org; Thu, 13 Oct 2005 18:13:13 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id j9DM0vj6095255; Thu, 13 Oct 2005 15:00:57 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200510132200.j9DM0vj6095255@cougar.icir.org> To: tsvwg@ietf.org From: Sally Floyd Date: Thu, 13 Oct 2005 15:00:57 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Pasi Sarolahti , Mark Allman Subject: [Tsvwg] draft-ietf-tsvwg-quickstart-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org We have submitted the revised version of the Quick-Start draft: http://www.icir.org/floyd/papers/draft-ietf-tsvwg-quickstart-01.txt http://www.icir.org/floyd/papers/draft-ietf-tsvwg-quickstart-01.ps We are hoping that this is ready for WG Last Call. The two major changes have been a change to a 30-bit QS Nonce instead of a 4-bit QS Nonce (based on a proposal from Guohan Lu and on feedback from Gorry Fairhurst), and significant revising of the section on IP Tunnels (based on extensive feedback from David Black and Joe Touch). Many many thanks to everyone. Any additional feedback would be appreciated. (And I will be in South Africa on vacation for the next two weeks, so my response to any feedback might be somewhat delayed...) - Sally http://www.icir.org/floyd/ Changes from draft-ietf-tsvwg-quickstart-00: * Added a 30-bit QS Nonce. Based on feedback from Guohan Lu and Gorry Fairhurst (and deleted the text about a possible four-bit QS nonce). * Added a new section "Quick-Start and IPsec AH", based on feedback from Joe Touch and David Black. * Revised "Quick-Start in IP Tunnels" Section, based on feedback from Joe Touch and David Black. * Added a section about "Possible Uses for the Reserved Fields". * Changes from feedback from Gorry Fairhurst: - Section 4.4, revised the explanation for reducing the congestion window when the first ACK for a Quick-Start packet is received. - Section 6.4, deleted the last sentence. - Minor editing changes. - Revised Section 4.6.2 to say that sender SHOULD send one packet with an initial RTO of three seconds. - Revised Section 4.6.3 to say that the TCP sender SHOULD use an initial RTO setting of three seconds. - Added text to Section 6.2 on Multiple Paths, discussing multi-path routing. - Clarified about GPRS round-trip times. - Clarified about PMTUD and the first window of data. - A small reorganization, rearranging sections. * Changes from feedback from Martin Duke: - Revised text about the size of QS requests. - Added some text to Section 4.1, about when to send QS requests. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 13 18:54:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBy6-0001PF-11; Thu, 13 Oct 2005 18:54:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBy1-0001OJ-QJ for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 18:54:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25998 for ; Thu, 13 Oct 2005 18:54:25 -0400 (EDT) Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQC8c-0004dt-7J for tsvwg@ietf.org; Thu, 13 Oct 2005 19:05:27 -0400 Received: from [10.0.1.5] (nak.isi.edu [128.9.168.79]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9DMrrO01172; Thu, 13 Oct 2005 15:53:53 -0700 (PDT) Date: Thu, 13 Oct 2005 15:53:46 -0700 From: Aaron Falk To: "Francois Le Faucheur (flefauch)" Subject: Re: [Tsvwg] WG Last Call on draft-tsvwg-rsvp-dste-00.txt Message-ID: <4796107B8B456C77DAA5EAAE@nak.isi.edu> In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org --On October 13, 2005 7:44:44 PM +0200 "Francois Le Faucheur (flefauch)" wrote: > > As per TSVWG final minutes (available from > http://www3.ietf.org/proceedings/05aug/index.html) > > " > Allison declares enough support to go ahead. The requirement will > be a least a couple of RSVP reviewers (from the RSVP team) to > write during WGLC. > " > > So I believe the agreement was that the "RSVP team" members review would > happen during the WGLC. Yes, I see. Sorry about that. > > PS: For one of my other documents (draft-lefaucheur-rsvp-ipsec-01.txt) > there was indeed a sort of "prerequisite" that some security experts > review the doc before the WG can moce too far with that document. > Perhaps this is where the confusion comes from. Probably. --aaron _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 13 18:54:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQByG-0001WN-Se; Thu, 13 Oct 2005 18:54:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQByE-0001W6-Oi for tsvwg@megatron.ietf.org; Thu, 13 Oct 2005 18:54:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26056 for ; Thu, 13 Oct 2005 18:54:38 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[wrbgpYtFv+d5AyV2F9odmhtwRt7keibX]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQC8p-0004ej-5v for tsvwg@ietf.org; Thu, 13 Oct 2005 19:05:40 -0400 Received: from ns.pigworks.openss7.net (IDENT:kSh35uopQGrIQ6ndC4r0YUQJn5AJCLUU@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j9DMs9c07968; Thu, 13 Oct 2005 16:54:09 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j9DMs8A16233; Thu, 13 Oct 2005 16:54:08 -0600 Date: Thu, 13 Oct 2005 16:54:08 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051013165407.A16196@openss7.org> References: <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> <20051012173213.D29834@openss7.org> <19f654a1cac7d6c70ff1794cc1d16d21@lurchi.franken.de> <20051013021112.A8132@openss7.org> <84B66FE5-5CF2-4E4E-B5E0-A13F93CF7F4D@lurchi.franken.de> <20051013120547.L13555@openss7.org> <434ECB6A.20100@stewart.chicago.il.us> 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: <434ECB6A.20100@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Thu, Oct 13, 2005 at 05:02:34PM -0400 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 j9DMs9c07968 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randall, On Thu, 13 Oct 2005, Randall Stewart wrote: > Brian F. G. Bidulock wrote: >=20 > >>If an endpoint/middlebox want to say that a particular port number > >>is not reachable it should use ABORT instead of ICMP(port unreachable= ). > >=20 > >=20 > > I don't think the SCTP specification (transport) should place require= ments > > on what the network layer should or should not send. > >=20 >=20 > I think the router requirments document already does this.. and I > don't remember anything in the I-G that requires a middlebox > to send anything.. if there is please point it out to me since > we should get rid of it.. >=20 No there was nothing in the document... Michael was arguing, I believe, that a non-SCTP aware host or router would not generate ICMP(port unreachable), but rather generate ICMP(prototcol unreachable), and an SCTP aware host or router would generate ABORT instead of ICMP(port unreachable), and concluding that ICMP(port unreachable) should be ignored when received by an SCTP capable node. My point was that the I-G does not (and should not) dictate when ICMP(port unreachable) is to be sent, or for what reasons. That is, indeed, up to the router requirements RFC to dictate. An SCTP implementation receiving ICMP(port unreachable) should not be required by the uncomping SCTP RFC to discard the messages, as in accordance with the router requirements, they may indicate to the sending SCTP that it can take action with regard to an association in the absense of an ABORT that the router is no longer required to send. Perhaps the receiving SCTP host should indeed process ICMP(port unreachable) rather than being required to discard it as Michael originally proposed. --brian --=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 tsvwg-bounces@ietf.org Fri Oct 14 10:59:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQR1S-0006VM-B9; Fri, 14 Oct 2005 10:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQR1Q-0006VE-So for tsvwg@megatron.ietf.org; Fri, 14 Oct 2005 10:59:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17484 for ; Fri, 14 Oct 2005 10:58:54 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQRC7-0006if-2u for tsvwg@ietf.org; Fri, 14 Oct 2005 11:10:04 -0400 Received: from [10.226.159.178] (ip-80-226-253-230.vodafone-net.de [80.226.253.230]) by ilsa.franken.de (Postfix) with ESMTP id 4829E245C4; Fri, 14 Oct 2005 16:58:36 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <20051013165407.A16196@openss7.org> References: <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> <20051012173213.D29834@openss7.org> <19f654a1cac7d6c70ff1794cc1d16d21@lurchi.franken.de> <20051013021112.A8132@openss7.org> <84B66FE5-5CF2-4E4E-B5E0-A13F93CF7F4D@lurchi.franken.de> <20051013120547.L13555@openss7.org> <434ECB6A.20100@stewart.chicago.il.us> <20051013165407.A16196@openss7.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <71E413A4-AE56-44AF-8E7B-7BEC6601F7C7@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Fri, 14 Oct 2005 16:58:30 +0200 To: bidulock@openss7.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Randall Stewart , Scott Bradner , Kacheong Poon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Dear all, my point is just to harmonize RFC 1122, Host Requirements, and the =20 future SCTP specification. RFC 1122 states: - An endpoint SHOULD delete the association on reception of an ICMP(protocol unreachable). - An endpoint MUST process an ICMP(port unreachable) like an ABORT. The first would require a change from MUST to SHOULD as indicated in my original mail. Currently the IG says that you must ignore ICMP(port unreachable). I do not want to change anything regarding the sending of this ICMP message, I'm only wondering if we should also change the IG or (what I would prefer) to not change the IG on the ICMP(port unreachable) processing and stating that this is a difference to RFC 1122. Best regards Michael On Oct 14, 2005, at 12:54 AM, Brian F. G. Bidulock wrote: > Randall, > > On Thu, 13 Oct 2005, Randall Stewart wrote: > > >> Brian F. G. Bidulock wrote: >> >> >>>> If an endpoint/middlebox want to say that a particular port number >>>> is not reachable it should use ABORT instead of ICMP(port =20 >>>> unreachable). >>>> >>> >>> >>> I don't think the SCTP specification (transport) should place =20 >>> requirements >>> on what the network layer should or should not send. >>> >>> >> >> I think the router requirments document already does this.. and I >> don't remember anything in the I-G that requires a middlebox >> to send anything.. if there is please point it out to me since >> we should get rid of it.. >> >> > > No there was nothing in the document... Michael was arguing, I =20 > believe, > that a non-SCTP aware host or router would not generate ICMP(port > unreachable), but rather generate ICMP(prototcol unreachable), and an > SCTP aware host or router would generate ABORT instead of ICMP(port > unreachable), and concluding that ICMP(port unreachable) should be > ignored when received by an SCTP capable node. > > My point was that the I-G does not (and should not) dictate when > ICMP(port unreachable) is to be sent, or for what reasons. That is, > indeed, up to the router requirements RFC to dictate. > > An SCTP implementation receiving ICMP(port unreachable) should not be > required by the uncomping SCTP RFC to discard the messages, as in > accordance with the router requirements, they may indicate to the > sending SCTP that it can take action with regard to an association > in the absense of an ABORT that the router is no longer required to > send. > > Perhaps the receiving SCTP host should indeed process ICMP(port > unreachable) rather than being required to discard it as Michael > originally proposed. > > --brian > > --=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 tsvwg-bounces@ietf.org Fri Oct 14 15:51:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVaM-0005kU-HI; Fri, 14 Oct 2005 15:51:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVZ8-0005QD-8V; Fri, 14 Oct 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07141; Fri, 14 Oct 2005 15:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVjr-0007nF-6t; Fri, 14 Oct 2005 16:01:12 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EQVZ3-0000m9-VX; Fri, 14 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 14 Oct 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-quickstart-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Quick-Start for TCP and IP Author(s) : S. Floyd, et al. Filename : draft-ietf-tsvwg-quickstart-01.txt,.ps Pages : 76 Date : 2005-10-14 This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and at times in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we describe its use with TCP. By using Quick-Start, a TCP host, say, host A, would indicate its desired sending rate in bytes per second, using a Quick Start Request option in the IP header of a TCP packet. Each router along the path could, in turn, either approve the requested rate, reduce the requested rate, or indicate that the Quick-Start request is not approved. If the Quick-Start request is not approved, then the sender would use the default congestion control mechanisms. The Quick-Start mechanism can determine if there are routers along the path that do not understand the Quick-Start Request option, or have not agreed to the Quick- Start rate request. TCP host B communicates the final rate request to TCP host A in a transport-level Quick-Start Response in an answering TCP packet. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and all of the routers along the path support the Quick-Start Request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-quickstart-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-quickstart-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-quickstart-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-14115030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-quickstart-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-quickstart-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-14115030.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --NextPart-- From tsvwg-bounces@ietf.org Fri Oct 14 17:05:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWkA-0007nB-Ft; Fri, 14 Oct 2005 17:05:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWk8-0007lq-Qc for tsvwg@megatron.ietf.org; Fri, 14 Oct 2005 17:05:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24788 for ; Fri, 14 Oct 2005 17:05:28 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[ohN/deCnBRftkU3K75EDgSfFmRMSBjLB]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWuu-0006H3-Nf for tsvwg@ietf.org; Fri, 14 Oct 2005 17:16:42 -0400 Received: from ns.pigworks.openss7.net (IDENT:qaSRT0Qz63G0HQQp8KX+aFfURtjLBXAo@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j9EL4nc00942; Fri, 14 Oct 2005 15:04:49 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j9EL4mj32078; Fri, 14 Oct 2005 15:04:48 -0600 Date: Fri, 14 Oct 2005 15:04:47 -0600 From: "Brian F. G. Bidulock" To: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051014150447.C31640@openss7.org> References: <4346A997.5070300@stewart.chicago.il.us> <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> <20051012173213.D29834@openss7.org> <19f654a1cac7d6c70ff1794cc1d16d21@lurchi.franken.de> <20051013021112.A8132@openss7.org> <84B66FE5-5CF2-4E4E-B5E0-A13F93CF7F4D@lurchi.franken.de> <20051013120547.L13555@openss7.org> <434ECB6A.20100@stewart.chicago.il.us> <20051013165407.A16196@openss7.org> <71E413A4-AE56-44AF-8E7B-7BEC6601F7C7@lurchi.franken.de> 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: <71E413A4-AE56-44AF-8E7B-7BEC6601F7C7@lurchi.franken.de>; from Michael.Tuexen@lurchi.franken.de on Fri, Oct 14, 2005 at 04:58:30PM +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 j9EL4nc00942 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Randall Stewart , Scott Bradner , Kacheong Poon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael, I would prefer if any necessary changes were made in RFC 1122. That is under the same WG is it not? --brian On Fri, 14 Oct 2005, Michael Tuexen wrote: > Dear all, >=20 > my point is just to harmonize RFC 1122, Host Requirements, and the =20 > future > SCTP specification. >=20 > RFC 1122 states: > - An endpoint SHOULD delete the association on reception of an > ICMP(protocol unreachable). > - An endpoint MUST process an ICMP(port unreachable) like an > ABORT. >=20 > The first would require a change from MUST to SHOULD as indicated > in my original mail. Currently the IG says that you must ignore > ICMP(port unreachable). I do not want to change anything regarding > the sending of this ICMP message, I'm only wondering if we should also > change the IG or (what I would prefer) to not change the IG on the > ICMP(port unreachable) processing and stating that this is a difference > to RFC 1122. >=20 > Best regards > Michael >=20 --=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 tsvwg-bounces@ietf.org Fri Oct 14 18:24:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXyo-00086K-7U; Fri, 14 Oct 2005 18:24:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXym-00086B-JE for tsvwg@megatron.ietf.org; Fri, 14 Oct 2005 18:24:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00328 for ; Fri, 14 Oct 2005 18:24:40 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQY9Y-0000NP-9I for tsvwg@ietf.org; Fri, 14 Oct 2005 18:35:54 -0400 Received: from [192.168.1.15] (p508F7011.dip.t-dialin.net [80.143.112.17]) by ilsa.franken.de (Postfix) with ESMTP id 64B8E246F0; Sat, 15 Oct 2005 00:24:35 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <20051014150447.C31640@openss7.org> References: <4346A997.5070300@stewart.chicago.il.us> <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> <20051012173213.D29834@openss7.org> <19f654a1cac7d6c70ff1794cc1d16d21@lurchi.franken.de> <20051013021112.A8132@openss7.org> <84B66FE5-5CF2-4E4E-B5E0-A13F93CF7F4D@lurchi.franken.de> <20051013120547.L13555@openss7.org> <434ECB6A.20100@stewart.chicago.il.us> <20051013165407.A16196@openss7.org> <71E413A4-AE56-44AF-8E7B-7BEC6601F7C7@lurchi.franken.de> <20051014150447.C31640@openss7.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <885F8670-4710-4828-9032-221E1B9BECCD@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG Date: Sat, 15 Oct 2005 00:24:32 +0200 To: bidulock@openss7.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Randall Stewart , Scott Bradner , Kacheong Poon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Brian, as far as I know there is noone working on a new version of RFC 1122. =20= And I do not see, that it is necessary. So what do you think about the text I suggested? Best regards Michael On Oct 14, 2005, at 11:04 PM, Brian F. G. Bidulock wrote: > Michael, > > I would prefer if any necessary changes were made in RFC 1122. =20 > That is > under the same WG is it not? > > --brian > > On Fri, 14 Oct 2005, Michael Tuexen wrote: > > >> Dear all, >> >> my point is just to harmonize RFC 1122, Host Requirements, and the >> future >> SCTP specification. >> >> RFC 1122 states: >> - An endpoint SHOULD delete the association on reception of an >> ICMP(protocol unreachable). >> - An endpoint MUST process an ICMP(port unreachable) like an >> ABORT. >> >> The first would require a change from MUST to SHOULD as indicated >> in my original mail. Currently the IG says that you must ignore >> ICMP(port unreachable). I do not want to change anything regarding >> the sending of this ICMP message, I'm only wondering if we should =20 >> also >> change the IG or (what I would prefer) to not change the IG on the >> ICMP(port unreachable) processing and stating that this is a =20 >> difference >> to RFC 1122. >> >> Best regards >> Michael >> >> > > --=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 tsvwg-bounces@ietf.org Sat Oct 15 06:29:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQjHl-0004u5-KM; Sat, 15 Oct 2005 06:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQjHk-0004tu-3u for tsvwg@megatron.ietf.org; Sat, 15 Oct 2005 06:29:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02488 for ; Sat, 15 Oct 2005 06:28:59 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQjSd-0008Ty-4D for tsvwg@ietf.org; Sat, 15 Oct 2005 06:40:20 -0400 Received: from [192.168.1.17] (p508F5FB0.dip.t-dialin.net [80.143.95.176]) by ilsa.franken.de (Postfix) with ESMTP id DD828245C5; Sat, 15 Oct 2005 12:28:48 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <921445D056CC0E4FAFA3F0566793E827013792D7@esebe104.NOE.Nokia.com> References: <921445D056CC0E4FAFA3F0566793E827013792D7@esebe104.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Tsvwg] Bytes used for calculation of the HMAC in SCTP Date: Sat, 15 Oct 2005 12:27:53 +0200 To: Ivan.Arias-Rodriguez@nokia.com X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi Ivan, I would prefer that also the padding of the final chunk is considered,=20= if the sender puts it in. I'll add some text. Best regards Michael On Oct 13, 2005, at 17:18 Uhr, Ivan.Arias-Rodriguez@nokia.com wrote: > Hi all! > > I guess I know the answer but I think it is not clear enough in = the=20 > draft. It is about the padding bytes of the chunks covered by the AUTH=20= > chunk. I suppose that the padding bytes of all the chunks but the last=20= > one are included in the calculation of the HMAC, but I would say that=20= > nothing regarding that is stated in the draft. > > Thanks! > > BR Iv=E1n Arias Rodr=EDguez > > _______________________________________________ > 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 tsvwg-bounces@ietf.org Sat Oct 15 09:57:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQmXS-00076e-H0; Sat, 15 Oct 2005 09:57:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQmXR-00076Y-A6 for tsvwg@megatron.ietf.org; Sat, 15 Oct 2005 09:57:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10875 for ; Sat, 15 Oct 2005 09:57:23 -0400 (EDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQmiM-0004X0-51 for tsvwg@ietf.org; Sat, 15 Oct 2005 10:08:47 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9FDtRmM027918; Sat, 15 Oct 2005 16:55:28 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Oct 2005 16:57:24 +0300 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Oct 2005 16:56:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] Bytes used for calculation of the HMAC in SCTP Date: Sat, 15 Oct 2005 16:56:37 +0300 Message-ID: <921445D056CC0E4FAFA3F0566793E827013796AA@esebe104.NOE.Nokia.com> Thread-Topic: [Tsvwg] Bytes used for calculation of the HMAC in SCTP Thread-Index: AcXRc1JEjhtgCzqJTpywlHPbA3CcYgAHNWKg To: X-OriginalArrivalTime: 15 Oct 2005 13:56:39.0983 (UTC) FILETIME=[443643F0:01C5D190] X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Well, actually, that would make easier the creation of the AUTH = chunk... Thanks! BR Iv=E1n Arias Rodr=EDguez=20 >-----Original Message----- >From: ext Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 >Sent: 15 October, 2005 13:28 >To: Arias-Rodriguez Ivan (Nokia-NRC/Helsinki) >Cc: tsvwg@ietf.org >Subject: Re: [Tsvwg] Bytes used for calculation of the HMAC in SCTP > >Hi Ivan, > >I would prefer that also the padding of the final chunk is=20 >considered, if the sender puts it in. > >I'll add some text. > >Best regards >Michael > >On Oct 13, 2005, at 17:18 Uhr, Ivan.Arias-Rodriguez@nokia.com wrote: > >> Hi all! >> >> I guess I know the answer but I think it is not clear=20 >enough in the=20 >> draft. It is about the padding bytes of the chunks covered=20 >by the AUTH=20 >> chunk. I suppose that the padding bytes of all the chunks=20 >but the last=20 >> one are included in the calculation of the HMAC, but I would=20 >say that=20 >> nothing regarding that is stated in the draft. >> >> Thanks! >> >> BR Iv=E1n Arias Rodr=EDguez >> >> _______________________________________________ >> 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 tsvwg-bounces@ietf.org Mon Oct 17 04:54:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQlD-0001Ko-43; Mon, 17 Oct 2005 04:54:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQlA-0001Kd-A0 for tsvwg@megatron.ietf.org; Mon, 17 Oct 2005 04:54:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26533 for ; Mon, 17 Oct 2005 04:54:12 -0400 (EDT) Received: from wall.ikr.uni-stuttgart.de ([129.69.170.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERQwS-00068k-Cy for tsvwg@ietf.org; Mon, 17 Oct 2005 05:06:01 -0400 Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id 418F456D44 for ; Mon, 17 Oct 2005 10:54:08 +0200 (CEST) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id 32D37BD604; Mon, 17 Oct 2005 10:54:08 +0200 (CEST) Received: from ikr.uni-stuttgart.de (pc35 [10.21.21.35]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id E03B5BD602 for ; Mon, 17 Oct 2005 10:54:07 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Mon, 17 Oct 2005 10:54:07 +0200 Date: Mon, 17 Oct 2005 10:54:07 +0200 From: Sebastian Kiesel To: tsvwg@ietf.org Message-ID: <20051017085407.GB15322@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on netsrv1 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [Tsvwg] New Internet Draft on SIMCO over SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Dear all, Please find below the announcement for a new Internet Draft that specifies how to transport SIMCO over SCTP. SIMCO is a rather simple, transaction based protocol for controlling firewalls and NATs. While this ID is primarily a concern of the MIDCOM WG it might be of interest here as well. Experience with a prototype implementation has shown that SIMCO over SCTP has several advantages over using TCP. Any comments are welcome. Thanks, Sebastian -- Sebastian Kiesel University of Stuttgart Tel: +49 711 685 7992 Institute of Communication Networks and Fax: +49 711 685 7983 Computer Engineering (IKR, formerly: IND) kiesel@ikr.uni-stuttgart.de Pfaffenwaldring 47, 70569 Stuttgart, Germany ----- Forwarded message from Internet-Drafts@ietf.org ----- X-Original-To: kiesel@ikr.uni-stuttgart.de Delivered-To: kiesel@ikr.uni-stuttgart.de To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 13 Oct 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: I-D ACTION:draft-kiesel-midcom-simco-sctp-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on netsrv1 X-Spam-Level: X-Spam-Status: No, hits=0.4 required=5.0 tests=MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.63 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIMCO over SCTP Author(s) : S. Kiesel Filename : draft-kiesel-midcom-simco-sctp-00.txt Pages : 13 Date : 2005-10-13 This document specifies how to use SCTP for the transport of the SIMCO (Version 3.0) protocol. SIMCO (SImple Middlebox COnfiguration) is a protocol that implements the MIDCOM semantics. It can be used for controlling middleboxes such as firewalls and network address translators. SCTP (Stream Control Transmission Protocol) is a transport layer protocol that is expected to have advantages for this type of application, compared to TCP, which is the default transport layer protocol for SIMCO. The specific requirements for SIMCO when using SCTP instead of TCP are specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kiesel-midcom-simco-sctp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kiesel-midcom-simco-sctp-00.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-kiesel-midcom-simco-sctp-00.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. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ----- End forwarded message ----- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 17 14:46:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERa0c-00020x-Le; Mon, 17 Oct 2005 14:46:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERa0a-00020p-Ka for tsvwg@megatron.ietf.org; Mon, 17 Oct 2005 14:46:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00482 for ; Mon, 17 Oct 2005 14:46:45 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERaBx-0006wh-7w for tsvwg@ietf.org; Mon, 17 Oct 2005 14:58:38 -0400 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j9HIwRXZ007697 for ; Mon, 17 Oct 2005 11:58:27 -0700 (MST) Received: from motorola.com (mvp-10-19-252-192.corp.mot.com [10.19.252.192]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j9HIwcVl012703; Mon, 17 Oct 2005 13:58:39 -0500 (CDT) Message-ID: <4353F1EA.4080806@motorola.com> Date: Mon, 17 Oct 2005 13:48:10 -0500 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: TSV WG list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Tsvwg] retransmission at multiple levels X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, all, I remember seeing a comments on this list a while ago that stated that there were some research results on issues related to performing retransmission at multiple levels in a stack. I'd appreciate it if some one could point me to that research. regards, -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 17 19:18:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EReFT-0005YJ-Ii; Mon, 17 Oct 2005 19:18:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EReFR-0005YE-Ts for tsvwg@megatron.ietf.org; Mon, 17 Oct 2005 19:18:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14164 for ; Mon, 17 Oct 2005 19:18:21 -0400 (EDT) Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EReQs-0007hf-1n for tsvwg@ietf.org; Mon, 17 Oct 2005 19:30:18 -0400 Received: from nak.isi.edu (nak.isi.edu [128.9.168.79]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HNHUO06537 for ; Mon, 17 Oct 2005 16:17:30 -0700 (PDT) Date: Mon, 17 Oct 2005 16:17:24 -0700 From: Aaron Falk To: tsvwg@ietf.org Message-ID: X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Updated XCP version: xcp-nodiv X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org All- We have completed an update on the XCP end-system and router code resulting in a release of xcp-nodiv for FreeBSD-5.3. The most significant change is that the per-packet router calculations no longer include division. This change is important because performing line-rate divisions on production routers is undesirable. To facilitate this change we changed the Throughput header field to carry RTT/Throughput. This value may be thought of as an idealized inter-packet time, although we just call it 'X'. The tarball also includes a matching protocol specification, modified analysis tools, and scripts for exercising the algorithm. We continue to develop the algorithm. Current work addresses identifying and responding appropriately to non-XCP queues, sharing bottleneck capacity fairly with Reno-style flows, evaluating performance under a variety of environments (e.g., intermittent links) and traffic models (e.g., web mice), and a network processor implementation. The tarball, specification (submitted for publication as draft-falk-xcp-spec-01.txt), and mailing list information can be found at . --aaron _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 18 14:11:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERvvU-0007WP-5D; Tue, 18 Oct 2005 14:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERvvS-0007VY-5s for tsvwg@megatron.ietf.org; Tue, 18 Oct 2005 14:11:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19954 for ; Tue, 18 Oct 2005 14:10:53 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERw71-000655-9Q for tsvwg@ietf.org; Tue, 18 Oct 2005 14:23:00 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j9IIAwQ5006964; Tue, 18 Oct 2005 14:10:59 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <43553AB2.40905@stewart.chicago.il.us> Date: Tue, 18 Oct 2005 14:10:58 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sebastian Kiesel Subject: Re: [Tsvwg] New Internet Draft on SIMCO over SCTP References: <20051017085407.GB15322@ikr.uni-stuttgart.de> In-Reply-To: <20051017085407.GB15322@ikr.uni-stuttgart.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Sebastian: Very nice draft... one typo I saw in my quick read.. In section 4.1 you typo'd SCTP as "SCPT"... other than that it looks good.. One other question I had.. now I have not read SIMCO so some of this is new to me.. so forgive me if I have something wrong.. In section 4.4.1.3 you mention a PID rule learned by other means.. so the agent does not know the mapping of what stream the message goes to (you mention "especially PS".. I assume this is the message type).. Anyway.. In section 4.4.2.x I did not see anything that had the server build a mapping of this aka keep the responses to the PS message (if such a thing exists) in the same stream... does that sort of thing need to be mentioned here? Just food for thought.. R Sebastian Kiesel wrote: > Dear all, > > Please find below the announcement for a new Internet Draft that > specifies how to transport SIMCO over SCTP. SIMCO is a rather simple, > transaction based protocol for controlling firewalls and NATs. While > this ID is primarily a concern of the MIDCOM WG it might be of interest > here as well. Experience with a prototype implementation has shown that > SIMCO over SCTP has several advantages over using TCP. Any comments are > welcome. > > Thanks, > Sebastian > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 18 15:50:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxTs-00072F-5Q; Tue, 18 Oct 2005 15:50:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxTJ-0006rS-64; Tue, 18 Oct 2005 15:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24401; Tue, 18 Oct 2005 15:49:57 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERxer-0000Ar-R6; Tue, 18 Oct 2005 16:02:02 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ERxTF-0001ZZ-S7; Tue, 18 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Oct 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctp-auth-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Authenticated Chunks for Stream Control Transmission Protocol (SCTP) Author(s) : M. Tuexen, et al. Filename : draft-ietf-tsvwg-sctp-auth-01.txt Pages : 15 Date : 2005-10-18 This document describes a new chunk type, several parameters and procedures for SCTP. This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-auth-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-sctp-auth-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-sctp-auth-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-18113035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-sctp-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctp-auth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-18113035.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --NextPart-- From tsvwg-bounces@ietf.org Tue Oct 18 15:54:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxXX-0007ta-Q0; Tue, 18 Oct 2005 15:54:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxXV-0007tE-Jx for tsvwg@megatron.ietf.org; Tue, 18 Oct 2005 15:54:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24908 for ; Tue, 18 Oct 2005 15:54:18 -0400 (EDT) Message-Id: <200510181954.PAA24908@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERxj5-0000OM-J7 for tsvwg@ietf.org; Tue, 18 Oct 2005 16:06:24 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ERxXS-0004u4-In; Tue, 18 Oct 2005 19:54:22 +0000 To: tsvwg@ietf.org Date: Tue, 18 Oct 2005 12:54:22 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: jmpolk@cisco.com, jon.peterson@neustar.biz Subject: [Tsvwg] A Third Chair for TSVWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, all, If you recall, the low responsiveness of the Chairs of this working group prompted the ADs of the WG (with encouragement from the community and our own management!) to try to find a a third Chair, to improve the WG's action. Jon and I received a few nominees and volunteers. There were a number who felt that they too would be unresponsive due to the the already great demands IETF makes on them. We interviewed and we cajoled; I didn't quite bribe, I think... Anyway, to our pleasure, James Polk has just agreed to serve as the third Chair, recusing himself from documents of his own, of course, and taking an energetic role right away. Welcome, James, and now, work begins! _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 18 20:04:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1Rr-0002fk-Np; Tue, 18 Oct 2005 20:04:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1Rp-0002fc-87 for tsvwg@megatron.ietf.org; Tue, 18 Oct 2005 20:04:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08115 for ; Tue, 18 Oct 2005 20:04:40 -0400 (EDT) Received: from wall.ikr.uni-stuttgart.de ([129.69.170.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES1dS-0000Hb-7I for tsvwg@ietf.org; Tue, 18 Oct 2005 20:16:50 -0400 Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4AAF556D14; Wed, 19 Oct 2005 02:04:30 +0200 (CEST) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id 40B04BD604; Wed, 19 Oct 2005 02:04:30 +0200 (CEST) Received: from ikr.uni-stuttgart.de (lnc5 [10.21.12.25]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id 089C1BD602; Wed, 19 Oct 2005 02:04:30 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Wed, 19 Oct 2005 02:04:30 +0200 Date: Wed, 19 Oct 2005 02:04:30 +0200 From: Sebastian Kiesel To: Randall Stewart Subject: Re: [Tsvwg] New Internet Draft on SIMCO over SCTP Message-ID: <20051019000430.GA10438@ikr.uni-stuttgart.de> References: <20051017085407.GB15322@ikr.uni-stuttgart.de> <43553AB2.40905@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43553AB2.40905@stewart.chicago.il.us> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on netsrv1 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randall, thank you for your comments, please see inline: On Tue, Oct 18, 2005 at 02:10:58PM -0400, Randall Stewart wrote: > Sebastian: > > Very nice draft... one typo I saw in my quick > read.. > > In section 4.1 you typo'd SCTP as "SCPT"... other > than that it looks good.. ok. thank you. it will be fixed in the next version. > One other question I had.. now I have not read SIMCO so > some of this is new to me.. so forgive me if I have something > wrong.. Let me briefly explain the relevant SIMCO mechanism: Under normal circumstances the agent ("client") asks the middlebox ("server") to establish a new policy rule, e.g., by means of a PER request. The middlebox creates the rule and assigns a PID to it. The PID is returned to the agent, e.g., in the PER positive reply. The agent uses the PID in later modify/delete requests to refer to this specific policy rule. However, there is one special case, if we consider high reliability solutions with redundant standby SIMCO agents. A (standby) SIMCO agent may send a PRL (Policy Rule List) request to get a list of all PIDs that are currently established in the middlebox. Then, it may send several PS (Policy Status) requests, each containing one PID, in order to get more information about the respective policy rule. > In section 4.4.1.3 you mention a PID rule learned by other > means.. so the agent does not know the mapping of what > stream the message goes to (you mention "especially PS".. > I assume this is the message type).. > > Anyway.. In section 4.4.2.x I did not see anything > that had the server build a mapping of this aka > keep the responses to the PS message (if such a thing > exists) in the same stream... does that sort of > thing need to be mentioned here? With respect to the normal case, one basic idea of my draft is that the agent shall remember the stream on which it received the message from which it learned the PID (last paragraph of 4.4.1.2.). This stream pair shall be used for all subsequent requests referring to this PID (first paragraph of 4.4.1.3.). The second paragraph of 4.4.1.3. refers to the special case. As the PRL reply may contain quite a large list of PIDs, it is not reasonable to remember the stream on which the PRL reply was received on for each of these PIDs. Instead, the agent should distribute the requests over all stream pairs. > Just food for thought.. Considering that piece of additional information about SIMCO, does the text now become clearer, or do you feel that I should reword something? Thank you, Sebastian -- Sebastian Kiesel University of Stuttgart Tel: +49 711 685 7992 Institute of Communication Networks and Fax: +49 711 685 7983 Computer Engineering (IKR, formerly: IND) kiesel@ikr.uni-stuttgart.de Pfaffenwaldring 47, 70569 Stuttgart, Germany _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Oct 19 09:28:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDzs-0004KW-5E; Wed, 19 Oct 2005 09:28:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDzq-0004K0-Qy for tsvwg@megatron.ietf.org; Wed, 19 Oct 2005 09:28:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16446 for ; Wed, 19 Oct 2005 09:28:37 -0400 (EDT) Received: from mailgw3a.lmco.com ([192.35.35.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESEBT-0003Uo-1K for tsvwg@ietf.org; Wed, 19 Oct 2005 09:40:55 -0400 Received: from emss09g01.ems.lmco.com (relay6.ems.lmco.com [166.17.13.59]) by mailgw3a.lmco.com (8.12.10/8.12.10) with ESMTP id j9JDSTWx008753; Wed, 19 Oct 2005 09:28:29 -0400 (EDT) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0IOM0000103GZ9@lmco.com>; Wed, 19 Oct 2005 09:28:28 -0400 (EDT) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0IOM00KG103FTS@lmco.com>; Wed, 19 Oct 2005 09:28:28 -0400 (EDT) Received: from EMSS09I01.us.lmco.com ([158.183.26.24]) by EMSS09I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Oct 2005 09:28:25 -0400 Received: from EMSS04M14.us.lmco.com ([162.16.20.50]) by EMSS09I01.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Oct 2005 09:27:59 -0400 Date: Wed, 19 Oct 2005 09:27:59 -0400 From: "Bose, Pratik" To: tsvwg@ietf.org Message-id: <37B6F612D86CA143B5F965E9EE8BD7AA0C0E0445@emss04m14.us.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Thread-Topic: SecDir Review: draft-lefaucheur-rsvp-ipsec-01.txt Thread-Index: AcXUL3F9YTIx2FerR2CUMaRazxnBXwABni8QAB5QgqA= content-class: urn:content-classes:message X-OriginalArrivalTime: 19 Oct 2005 13:27:59.0693 (UTC) FILETIME=[EC7DD7D0:01C5D4B0] X-Spam-Score: 0.3 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: jmpolk@cisco.com, jon.peterson@neustar.biz, mankin@psg.com Subject: [Tsvwg] FW: SecDir Review: draft-lefaucheur-rsvp-ipsec-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2078917697==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. --===============2078917697== Content-type: multipart/alternative; boundary="Boundary_(ID_D92D9+cs8OXh6N0fD3Bp4A)" content-class: urn:content-classes:message This is a multi-part message in MIME format. --Boundary_(ID_D92D9+cs8OXh6N0fD3Bp4A) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, As directed by the chair in Paris, the authors of draft-lefaucheur-rsvp-ipsec-01.txt requested for a security review of the document. This has been initiated by the Security AD as per email below. Thanks, Pratik _____ From: Russ Housley [mailto:housley@vigilsec.com] Sent: Tuesday, October 18, 2005 6:01 PM To: sra@hactrn.net; ldondeti@qualcomm.com; kent@bbn.com Cc: Bose, Pratik; mankin@psg.com Subject: SecDir Review: draft-lefaucheur-rsvp-ipsec-01.txt Rob, Lakshminath, and Steve: Please review draft-lefaucheur-rsvp-ipsec-01.txt Thanks, Russ --Boundary_(ID_D92D9+cs8OXh6N0fD3Bp4A) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT
Hi,
 
As directed by the chair in Paris, the authors of draft-lefaucheur-rsvp-ipsec-01.txt requested for a security review of the document. This has been initiated by the Security AD as per email below.
 
Thanks,
 
Pratik

From: Russ Housley [mailto:housley@vigilsec.com]
Sent: Tuesday, October 18, 2005 6:01 PM
To: sra@hactrn.net; ldondeti@qualcomm.com; kent@bbn.com
Cc: Bose, Pratik; mankin@psg.com
Subject: SecDir Review: draft-lefaucheur-rsvp-ipsec-01.txt

Rob, Lakshminath, and Steve:

Please review draft-lefaucheur-rsvp-ipsec-01.txt

Thanks,
   Russ --Boundary_(ID_D92D9+cs8OXh6N0fD3Bp4A)-- --===============2078917697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============2078917697==-- From tsvwg-bounces@ietf.org Wed Oct 19 14:21:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIZH-0002xk-Il; Wed, 19 Oct 2005 14:21:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIZF-0002xf-Vq for tsvwg@megatron.ietf.org; Wed, 19 Oct 2005 14:21:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04581 for ; Wed, 19 Oct 2005 14:21:28 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESIl1-00045b-Om for tsvwg@ietf.org; Wed, 19 Oct 2005 14:33:49 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA10346 for ; Wed, 19 Oct 2005 11:21:27 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9JILQJ11786 for ; Wed, 19 Oct 2005 11:21:26 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 11:21:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2005 11:21:25 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369678@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: WG Last Call Thread-Index: AcXU2epHjPX+0JlAQ9ixplSO3ZMr5w== From: "Drake, John E" To: X-OriginalArrivalTime: 19 Oct 2005 18:21:26.0338 (UTC) FILETIME=[EADEAA20:01C5D4D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] WG Last Call X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, Whatever happened to the WG last call for draft-tsvwg-rsvp-dste-00.txt (RSVP Aggregation over MPLS TE tunnels)? I thought a decision was made at the Paris meeting to issue a last call for this I-D. Thanks, John John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo, CA 90245 john.e.drake2@boeing.com (412) 370-3108 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Oct 19 14:40:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIr8-0004z0-Lq; Wed, 19 Oct 2005 14:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIr7-0004ye-1T for tsvwg@megatron.ietf.org; Wed, 19 Oct 2005 14:40:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05906 for ; Wed, 19 Oct 2005 14:39:55 -0400 (EDT) Message-Id: <200510191839.OAA05906@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESJ2t-0004jl-U7 for tsvwg@ietf.org; Wed, 19 Oct 2005 14:52:16 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESIr5-000LIp-OI; Wed, 19 Oct 2005 18:40:03 +0000 To: "Drake, John E" Subject: Re: [Tsvwg] WG Last Call Date: Wed, 19 Oct 2005 11:40:03 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org John, The backlog (things like not getting to this and other Last Calls, not getting to closing the SCTP IG Last Call) is going to be dealt with now that the *server has been upgraded*! See mail later today. Allison, Jon, James _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Oct 19 14:42:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIto-0005qP-Dr; Wed, 19 Oct 2005 14:42:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESItn-0005qG-4a for tsvwg@megatron.ietf.org; Wed, 19 Oct 2005 14:42:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06052 for ; Wed, 19 Oct 2005 14:42:41 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESJ5Z-0004nY-1v for tsvwg@ietf.org; Wed, 19 Oct 2005 14:55:02 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA17353; Wed, 19 Oct 2005 13:42:39 -0500 (CDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9JIgdm14667; Wed, 19 Oct 2005 13:42:39 -0500 (CDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 11:42:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] WG Last Call Date: Wed, 19 Oct 2005 11:42:18 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC836967C@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: [Tsvwg] WG Last Call Thread-Index: AcXU3L5oKANDHSOcTS6NXPeVtnjXUAAABA+w From: "Drake, John E" To: "Allison Mankin" X-OriginalArrivalTime: 19 Oct 2005 18:42:19.0469 (UTC) FILETIME=[D5CB47D0:01C5D4DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Excellent, thanks > -----Original Message----- > From: Allison Mankin [mailto:mankin@psg.com] > Sent: Wednesday, October 19, 2005 11:40 AM > To: Drake, John E > Cc: tsvwg@ietf.org > Subject: Re: [Tsvwg] WG Last Call >=20 > John, >=20 > The backlog (things like not getting to > this and other Last Calls, not getting to > closing the SCTP IG Last Call) is going to be dealt with > now that the *server has been upgraded*! >=20 > See mail later today. >=20 > Allison, Jon, James _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Oct 19 15:55:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESK1m-00044C-3R; Wed, 19 Oct 2005 15:55:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESK1i-0003wk-F2 for tsvwg@megatron.ietf.org; Wed, 19 Oct 2005 15:55:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10038 for ; Wed, 19 Oct 2005 15:54:56 -0400 (EDT) Received: from mailer2.psc.edu ([128.182.66.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESKDV-0006zE-3I for tsvwg@ietf.org; Wed, 19 Oct 2005 16:07:18 -0400 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer2.psc.edu (8.13.4/8.13.3) with ESMTP id j9JJt27G005700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Oct 2005 15:55:02 -0400 (EDT) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.12.11/8.12.10) with ESMTP id j9JJt1QK025747 for ; Wed, 19 Oct 2005 15:55:01 -0400 Date: Wed, 19 Oct 2005 15:55:01 -0400 (EDT) From: Matt Mathis To: Transport WG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Tsvwg] Pushing to complete TCP-ESTATS-MIB X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org We are preparing the TCP extended statistics MIB for the home stretch. It would be really great to get any feedback before going for MIB doctor review and then last call. The current live draft can be obtained from: http://www.psc.edu/~mathis/TcpExtendedMib/draft-ietf-tsvwg-tcp-mib-extension-XX.txt I am currently scrubbing nits, but do not expect any substantial changes in the next few days. The published draft will be -08. The most recent change was to restructure the tables (yet again) to reduce the cost of a minimal implementation, yet make it as easy and attractive as possible to incrementally add additional optional objects. I am really looking forward to being done with this. Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 20 07:16:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYPg-00008s-U6; Thu, 20 Oct 2005 07:16:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYPX-00005l-RL for tsvwg@megatron.ietf.org; Thu, 20 Oct 2005 07:16:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02878 for ; Thu, 20 Oct 2005 07:16:30 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESYbR-0004BM-Lw for tsvwg@ietf.org; Thu, 20 Oct 2005 07:28:59 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j9KBGIQ5023296; Thu, 20 Oct 2005 07:16:27 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <43577C82.2060205@stewart.chicago.il.us> Date: Thu, 20 Oct 2005 07:16:18 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Tsvwg] ICMP issue with SCTP IG References: <20050921162304.A29088@openss7.org> <28d6f7b73746b7bbe5b706a75222ce50@lurchi.franken.de> <20050922045114.B6756@openss7.org> <69d50fe7d87f21c6298f1f561145c166@lurchi.franken.de> <20050923033810.B18747@openss7.org> <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> <20051011163216.A12351@openss7.org> In-Reply-To: <20051011163216.A12351@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, Michael Tuexen , Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Brian F. G. Bidulock wrote: > Randall, > > On Fri, 07 Oct 2005, Randall Stewart wrote: > > >>All: >> >>In an attempt to draw this discussion and all the points >>we have discussed to a close here is the text I am proposing >>we add to the I-G. This I think covers all of our issues... >> >>Our new section 11.5 now looks as follows: >> >>********************************************************* >>--------- >>New text >>--------- >> >>11.5 Protection of non-SCTP capable hosts. >> >>To provide non-SCTP capable host with the same level of >>protection against attacks as SCTP capable ones all SCTP >>stacks MUST implement the ICMP handling described in Appendix C. > > > I think this is too broad. The Appendix is full of procedures > for ignoring ICMP messages. I do not see how ignoring ICMP messages > ever protects a non-SCTP capable host. Can this MUST be restricted > to only those procedures in Appendix C that actually protect non-SCTP > capable hosts? That is... hey! Where in the Appendix C below does it > even say to stop on Protocol Unrechable? I can't find it there. > Let me see if I can first and formost of all tweak the wording in the appendix for the throw aways to be "may" or "should".. as to the question.. ICMP8 says: " ICMP8) If the ICMP code is a "Unrecognized next header type encountered" or a "Protocol Unreachable" treat this message as an abort with the T bit set. " So I think that covers it... But you are right in that we need to tweak things just a bit so that only things like ICMP8 are a MUST and the other things, such as ICMP1: " ICMP1) Ignore all ICMPv4 messages where the type field is not set to "Destination Unreachable". " One MAY do.. but does not have to.. > >>When an SCTP stack receives a packet containing multiple >>control or DATA chunks and the processing of the packet >>requires the sending of multiple chunks in response, >>the sender of the response chunk('s) MUST NOT send >>more than one packet. If bundling is supported multiple >>response chunks that fit into a single packet MAY be >>bundled together into one single response packet. If bundling >>is not supported then the sender MUST NOT send more >>than one response chunk and MUST discard all other >>responses. Note that this rule does NOT apply to a >>SACK chunk since a SACK chunk is, in itself, a response >>to DATA and a SACK does not require a response of more DATA. >> >>An SCTP implementation SHOULD abort the association if >>it receives a SACK acknowledging a TSN which has not been sent. >> >>An SCTP implementation that receives an INIT that would >>require a large packet in response, due to the inclusion >>of multiple ERROR parameters, MAY (at its discrection) >>elect to omit some or all of the ERROR parameters >>to reduce the size of the INIT-ACK. Due to a combination >>of the size of the COOKIE parameter and the number >>of addresses a receiver of an INIT may be indicating >>to a peer, it is always possible that the INIT-ACK will >>be larger than the original INIT. An SCTP implementation >>SHOULD attempt to make the INIT-ACK as small as possible >>to reduce the possibility of byte amplification attacks. > > > Yes, this text is excellent. > > >>************************************************************* >>The ICMP section that goes with it looks as follows: >>************************************************************* >>--------- >>New text: (Appendix C) >>--------- >> >>Appendix C ICMP Handling >> >>Whenever an ICMP message is received by an SCTP endpoint the >>following procedures MUST be followed to assure proper >>utilization of the information being provided by layer 3. >> >>ICMP1) Ignore all ICMPv4 messages where the type field is >> not set to "Destination Unreachable". >> >>ICMP2) Ignore all ICMPv6 messages where the type field is >> not "Destination Unreachable, "Parameter Problem" or >> "Packet Too Big". >> >>ICMP3) Ignore any ICMPv4 messages where the code does not >> indicate "Protocol Unreachable" or "Fragmentation Needed". >> >>ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if >> the code is not "Unrecognized next header type encountered". >> >>ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the >> association which sent the message that ICMP is responding to. >> If the association cannot be found, ignore the ICMP message. >> >>ICMP6) Validate that the verification tag contained in the ICMP >> message matches the verification tag of the peer. >> If the verification tag is not 0 and does NOT match, >> discard the ICMP message. If it is 0 and the ICMP message contains >> enough bytes to verify that the chunk type is an INIT chunk >> and that the initiate tag matches the tag of the peer continue >> with ICMP7. If the ICMP message is too short, the chunk type >> or the initiate tag does not match, silently discard the packet. >> >>ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 >> "Fragmentation Needed" process this information as defined for >> PATH MTU discovery. >> >>ICMP8) If the ICMP code is a "Unrecognized next header type >> encountered" or a "Protocol Unreachable" treat this message >> as an abort with the T bit set if it does not contain an >> INIT chunk. If it does contain an INIT chunk and the association >> is in COOKIE-WAIT state, handle the ICMP message like an ABORT. >> >>ICMP9) If the ICMP code is an "Unrecognized next header type >> encountered" or a "Protocol Unreachable" then the message >> MUST be treated as an abort with the T bit set, checking >> the Verification Tag in the ICMP message for validation. >> >>ICMP10)If the ICMPv6 code is "Destination Unreachable" the >> implementation MAY mark the destination into the unreachable >> state or alternatively increment the path error counter. >> >>************************************************************************* >>The path verification procedure end up as follows: >>************************************************************************ >>--------- >>New text: (Section 5.4) >>--------- >>5.4 Path Verification >> >>During association estabilishment the two peers >>exchange a list of addresses. In the predominant case >>these lists accurately represent the addresses owned >>by each peer. However there exists the possibility that >>a mis-behaving peer may supply addresses that it does >>not own. To prevent this the following rules are applied >>to all addresses of the new association: >> >>1) Any address passed to the sender of the INIT by its >> upper layer is automatically considered to be CONFIRMED. >> >>2) For the receiver of the COOKIE-ECHO the only CONFIRMED >> address is the one that the INIT-ACK was sent to. >> >>3) All other addresses not covered by rules 1 and 2 are considered >> UNCONFIRMED and are subject to probing for verification. >> >>To probe an address for verification, an endpoint will send >>HEARTBEAT's including a 64 bit random nonce and a path >>indicator (to identify the address that the HEARTBEAT >>is sent to) within the HEARTBEAT parameter. >> >>Upon reception of the HEARTBEAT-ACK a verification is >>made that the nonce included in the HEARTBEAT parameter >>is the one sent to the address indicated inside the >>HEARTBEAT parameter. When this match occurs, the address >>that the original HEARTBEAT was sent to is now considered >>CONFIRMED and available for normal data transfer. >> >>These probing proceedures are started when an association >>moves to the ESTABLISHED state and are ended when all >>paths are confirmed. > > > Above sounds good. > > >>Each RTO a probe may be sent on an active UNCONFIRMED path >>in an attempt to move it to to the CONFIRMED state. >>If during this probing the path becomes inactive this rate >>is lowered to the normal HEARTBEAT rate. At the expiration >>of the RTO timer the error counter of any path that was >>probed but not CONFIRMED is incremented by one and subjected >>to path failure detection defined in section 8.2. When probing >>UNCONFIRMED addresses, however, the association overall error count >>is NOT incremented. > > > Why not increment the association error count? Do we not want > the association with bogus addresses in it to fail just as quickly > as the one with all good addresses? I think the reverse might be > desirable: that is to peg failures of unconfirmed addresses against > the association at a faster rate (say double). I don't see any > problem with applying the same policy with regard to association > error peg counts to both confirmed and unconfirmed addresses. If you peg the association error counter as well .. you have a situation that may cause you to fail the association for a good guy.. Consider: E-A E-Z --SRC-IP1:INIT(IP1, IP2, IP3, IP4, IP5, IP6)-------> ....association comes up.... ** IP2-6 are down.. maybe there Inet provider is broken or down.. So, now E-Z starts to do 1 per RTO+jitter verification, and E-A's app has sent a request to compute pie to the Nth place and return the result or some such thing that means there will be no result for some time... so there is no data to send for say 2minutes before the server on E-Z responds... -----IP-1:COOKE-ECHO+DATA----------> <-------IP-1:COOKIE-ACK+SACK------- IP-2<-----HB+N------ RTO IP-3<-----HB+N------ RTO IP-4<-----HB+N------ RTO IP-5<-----HB+N------ RTO IP-6<-----HB+N------ RTO IP-2<-----HB+N------ RTO IP-3<-----HB+N------ RTO IP-4<-----HB+N------ RTO IP-5<-----HB+N------ RTO What will happen is our valid peer.. with valid address may not be able to get a HB to IP-1, due to the timing.. and thus the association fails... If the guy is an attacker, there is a good chance someone will send back an ICMP or ABORT to tear the association.. I don't think it is worth having a valid scenario that will tear apart the association when it should not... that is why I put the restriction in (note I did see this behavior in testing at one point... of course that was with HB.Max.Burst set at 4... which just emphasises a problem .. even at 1 you could hit this...) > > >>The number of HEARTBEATS sent at each RTO SHOULD be limited >>by the HB.Max.Burst parameter. It is an implementation decision >>as to how to distribute HEARTBEATS to the peers addresses >>for path verification. >> >>Whenever a path is confirmed an indication MAY be given to >>to the upper layer. >> >>An endpoint MUST NOT send any chunks to an UNCONFIRMED >>address with the following exceptions: >> >>- A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED >> address. >> >>- A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address. >> >>- A COOKIE-ACK MAY be sent to an UNCONFIRMED address but >> it MUST be bundled with a HEARTBEAT including a nonce. >> An implementation that does NOT support bundling MUST >> NOT send a COOKIE-ACK to an UNCONFIRMED address. >> >>- A COOKE-ECHO MAY be sent to an UNCONFIRMED address but >> it MUST be bundled with a HEARTBEAT including a nonce >> and the packet MUST NOT exceed the path MTU. If the >> implementation does NOT support bundling or the bundled >> COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed >> the path MTU, then the implemenation MUST NOT send >> a COOKIE-ECHO to an UNCONFIRMED address. > > > We need to be able to send COOKIE-ACK,SACK,DATA in response to > COOKIE-ECHO,DATA,[DATA]. Can we make this COOKIE-ACK,HB[nonce], > SACK,DATA,[DATA] to unverified addresses. But if we do this we are doing byte amplification... Adding 4 bytes to a HB+nonce (the cookie-ack) is not much of an amplification.. but the minute you start allowing DATA to be added you WILL get cases of amplification.. which we are trying to prevent.. I think just a CA+HB-nonce... will a) prevent amplification and b) Still allow at least 2 address to get verified quickly.. and the rest can go through the normal verification process... > > >>************************************************************* >>With the corresponding parameter defaults as follows: >>************************************************************* >>The following protocol parameters are RECOMMENDED: >> >>RTO.Initial - 3 seconds >>RTO.Min - 1 second >>RTO.Max - 60 seconds >>Max.Burst - 4 >>RTO.Alpha - 1/8 >>RTO.Beta - 1/4 >>Valid.Cookie.Life - 60 seconds >>Association.Max.Retrans - 10 attempts >>Path.Max.Retrans - 5 attempts (per destination address) >>Max.Init.Retransmits - 8 attempts >>HB.Interval - 30 seconds >>HB.Max.Burst - 1 >> >>**************************************************************** >> >> >>I think this covers all that we had talked about... the byte >>amplification of INIT-ACK is mentioned/noted and I think >>we should move on... Implementations can minimize there >>INIT-ACK's as they deem appropriate and are now allowed >>to omit errors... >> >>Note, commens and suggested changes, as always, are most >>welcome :-D > > > Overall very good. Thank you for your wordsmithing efforts. I will attempt to get these final changes in today.. and run it by the list... (the ICMP tweaks).. I also have a couple of other emails highlighted... that I want to get through.. I would like to have this all wrappped up and submitted before the cutoff on Monday.. which means I must be done Sunday :-0 R > > --brian > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 20 07:24:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYWm-00046q-R9; Thu, 20 Oct 2005 07:24:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYWl-00044N-2q for tsvwg@megatron.ietf.org; Thu, 20 Oct 2005 07:24:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03193 for ; Thu, 20 Oct 2005 07:23:57 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESYig-0004P5-Pf for tsvwg@ietf.org; Thu, 20 Oct 2005 07:36:27 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j9KBO2Q5023317; Thu, 20 Oct 2005 07:24:02 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <43577E52.8010202@stewart.chicago.il.us> Date: Thu, 20 Oct 2005 07:24:02 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Meyknecht, Bernward" Subject: Re: AW: [Tsvwg] ICMP issue with SCTP IG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: bidulock@openss7.org, tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Bernward: I agree with Michael and Brian.. and I think most all the other developers that have not chimed in here objecting (I think you are alone in objecting to the must).. This is a MUST R Meyknecht, Bernward wrote: > > Hi all, > > I'm not content with the new section on ICMP handling for the SCTP IG, incl. > the 'MUST' for ICMP handling within an SCTP specification, and propose to replace > it by a weaker wording and moving the section to another place. > > I would of course never propose to delete the ICMP section from the IG, but for me > it is something to be described in an appendix of the SCTP specification, as it is > done in the actual issue 15 of the IG, without the wording 'MUST', but with > something like '...should be followed to assure proper utilization of the information > being provided by layer 3', which is the current wording. > > Adding ICMP handling to SCTP was motivated by attack scenarios described in the > draft draft-stewart-tsvwg-sctpthreat-03.txt, okay. > But the other enhancements being described for SCTP within the new IG section, > i.e. amplification control, path verification (small hb.max.burst) and aborting > when receiving an ack for an unsent TSN, etc. > these are exactlay the counter measures taken on SCTP level to prevent the > attacks. Besides that there is a number of circumstances on which the attacks > depend, i.e. which are necessary to allow the attack at all. > With an SCTP implementation having the SCTP enhancements as mentioned above I > don't see the relevance of these attacks on SCTP any more. > > Besides that I see ICMP as something belonging to a layer below SCTP, the SCTP > RFC should describe only the SCTP level, hints on ICMP handling could be part > of an extra document/draft, even in a future RFC. > > Kind regards, -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 20 07:27:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYZo-0005c3-KO; Thu, 20 Oct 2005 07:27:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYZm-0005Yz-SI for tsvwg@megatron.ietf.org; Thu, 20 Oct 2005 07:27:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03290 for ; Thu, 20 Oct 2005 07:27:05 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESYlh-0004Tc-Uj for tsvwg@ietf.org; Thu, 20 Oct 2005 07:39:34 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j9KBRAQ5023334; Thu, 20 Oct 2005 07:27:10 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <43577F0D.6070800@stewart.chicago.il.us> Date: Thu, 20 Oct 2005 07:27:09 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG References: <260bfb19542b53463de0c3410fc4badc@lurchi.franken.de> <43305CE9.1000408@stewart.chicago.il.us> <20050921015053.A10788@openss7.org> <40738d159d9c90c6d69f7ee3e6210db1@lurchi.franken.de> <20050921111932.A26114@openss7.org> <20050921162304.A29088@openss7.org> <28d6f7b73746b7bbe5b706a75222ce50@lurchi.franken.de> <20050922045114.B6756@openss7.org> <69d50fe7d87f21c6298f1f561145c166@lurchi.franken.de> <20050923033810.B18747@openss7.org> <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> In-Reply-To: <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Content-Transfer-Encoding: 7bit Cc: bidulock@openss7.org, tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael: I agree with you.. I will see if I cannot incorporate your suggestions in this next draft I put on the list.. R Michael Tuexen wrote: > Randy, > > in general I like the text you submitted. But I think it > might be good to have the SCTP procedure in tune with the > ones described in RFC 1122 (Host Requirements). > > Section 3.2.2.1 of RFC 1122 states > A host SHOULD generate Destination Unreachable messages with > code: > > 2 (Protocol Unreachable), when the designated transport > protocol is not supported; > > A Destination Unreachable message that is received MUST be > reported to the transport layer. The transport layer SHOULD > use the information appropriately; for example, see Sections > 4.1.3.3, 4.2.3.9, and 4.2.4 below. > > and section 4.2.3.9 states (for TCP) > > o Destination Unreachable -- codes 2-4 > > These are hard error conditions, so TCP SHOULD abort > the connection. > > So I think to harmonize the future SCTP RFC with RFC 1122, we should > change > > ICMP9) If the ICMP code is an "Unrecognized next header type > encountered" or a "Protocol Unreachable" then the message > MUST be treated as an abort with the T bit set, checking > the Verification Tag in the ICMP message for validation. > > to > > ICMP9) If the ICMP code is an "Unrecognized next header type > encountered" or a "Protocol Unreachable" then the message > SHOULD be treated as an abort with the T bit set, checking > the Verification Tag in the ICMP message for validation. > > Furthermore RFC 1122 states in section 3.2.2.1 > > A transport protocol > that has its own mechanism for notifying the sender that a > port is unreachable (e.g., TCP, which sends RST segments) > MUST nevertheless accept an ICMP Port Unreachable for the > same purpose. > > This covers SCTP too. So we should either add this rule to the ICMP > processing > rules or make an Implementation Note that we do not require an SCTP > implementation > to do it. I would prefer the second, because either the receiver of an > INIT supports > SCTP and sends back an ABORT or does not support SCTP and sends back an > ICMP(protocol unreachable). So an ICMP(port unreachable) should never > be generated. > So I would like to make an explicit statement, that an SCTP > implementation SHOULD > not process an ICMP(port unreachable). > > What do you and others think? > > Best regards > Michael > > > On Oct 7, 2005, at 7:00 PM, Randall Stewart wrote: > >> All: >> >> In an attempt to draw this discussion and all the points >> we have discussed to a close here is the text I am proposing >> we add to the I-G. This I think covers all of our issues... >> >> Our new section 11.5 now looks as follows: >> >> ********************************************************* >> --------- >> New text >> --------- >> >> 11.5 Protection of non-SCTP capable hosts. >> >> To provide non-SCTP capable host with the same level of >> protection against attacks as SCTP capable ones all SCTP >> stacks MUST implement the ICMP handling described in Appendix C. >> >> When an SCTP stack receives a packet containing multiple >> control or DATA chunks and the processing of the packet >> requires the sending of multiple chunks in response, >> the sender of the response chunk('s) MUST NOT send >> more than one packet. If bundling is supported multiple >> response chunks that fit into a single packet MAY be >> bundled together into one single response packet. If bundling >> is not supported then the sender MUST NOT send more >> than one response chunk and MUST discard all other >> responses. Note that this rule does NOT apply to a >> SACK chunk since a SACK chunk is, in itself, a response >> to DATA and a SACK does not require a response of more DATA. >> >> An SCTP implementation SHOULD abort the association if >> it receives a SACK acknowledging a TSN which has not been sent. >> >> An SCTP implementation that receives an INIT that would >> require a large packet in response, due to the inclusion >> of multiple ERROR parameters, MAY (at its discrection) >> elect to omit some or all of the ERROR parameters >> to reduce the size of the INIT-ACK. Due to a combination >> of the size of the COOKIE parameter and the number >> of addresses a receiver of an INIT may be indicating >> to a peer, it is always possible that the INIT-ACK will >> be larger than the original INIT. An SCTP implementation >> SHOULD attempt to make the INIT-ACK as small as possible >> to reduce the possibility of byte amplification attacks. >> >> ************************************************************* >> The ICMP section that goes with it looks as follows: >> ************************************************************* >> --------- >> New text: (Appendix C) >> --------- >> >> Appendix C ICMP Handling >> >> Whenever an ICMP message is received by an SCTP endpoint the >> following procedures MUST be followed to assure proper >> utilization of the information being provided by layer 3. >> >> ICMP1) Ignore all ICMPv4 messages where the type field is >> not set to "Destination Unreachable". >> >> ICMP2) Ignore all ICMPv6 messages where the type field is >> not "Destination Unreachable, "Parameter Problem" or >> "Packet Too Big". >> >> ICMP3) Ignore any ICMPv4 messages where the code does not >> indicate "Protocol Unreachable" or "Fragmentation Needed". >> >> ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if >> the code is not "Unrecognized next header type encountered". >> >> ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the >> association which sent the message that ICMP is responding to. >> If the association cannot be found, ignore the ICMP message. >> >> ICMP6) Validate that the verification tag contained in the ICMP >> message matches the verification tag of the peer. >> If the verification tag is not 0 and does NOT match, >> discard the ICMP message. If it is 0 and the ICMP message >> contains >> enough bytes to verify that the chunk type is an INIT chunk >> and that the initiate tag matches the tag of the peer continue >> with ICMP7. If the ICMP message is too short, the chunk type >> or the initiate tag does not match, silently discard the packet. >> >> ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 >> "Fragmentation Needed" process this information as defined for >> PATH MTU discovery. >> >> ICMP8) If the ICMP code is a "Unrecognized next header type >> encountered" or a "Protocol Unreachable" treat this message >> as an abort with the T bit set if it does not contain an >> INIT chunk. If it does contain an INIT chunk and the association >> is in COOKIE-WAIT state, handle the ICMP message like an ABORT. >> >> ICMP9) If the ICMP code is an "Unrecognized next header type >> encountered" or a "Protocol Unreachable" then the message >> MUST be treated as an abort with the T bit set, checking >> the Verification Tag in the ICMP message for validation. >> >> ICMP10)If the ICMPv6 code is "Destination Unreachable" the >> implementation MAY mark the destination into the unreachable >> state or alternatively increment the path error counter. >> >> ********************************************************************** >> *** >> The path verification procedure end up as follows: >> ********************************************************************** ** >> --------- >> New text: (Section 5.4) >> --------- >> 5.4 Path Verification >> >> During association estabilishment the two peers >> exchange a list of addresses. In the predominant case >> these lists accurately represent the addresses owned >> by each peer. However there exists the possibility that >> a mis-behaving peer may supply addresses that it does >> not own. To prevent this the following rules are applied >> to all addresses of the new association: >> >> 1) Any address passed to the sender of the INIT by its >> upper layer is automatically considered to be CONFIRMED. >> >> 2) For the receiver of the COOKIE-ECHO the only CONFIRMED >> address is the one that the INIT-ACK was sent to. >> >> 3) All other addresses not covered by rules 1 and 2 are considered >> UNCONFIRMED and are subject to probing for verification. >> >> To probe an address for verification, an endpoint will send >> HEARTBEAT's including a 64 bit random nonce and a path >> indicator (to identify the address that the HEARTBEAT >> is sent to) within the HEARTBEAT parameter. >> >> Upon reception of the HEARTBEAT-ACK a verification is >> made that the nonce included in the HEARTBEAT parameter >> is the one sent to the address indicated inside the >> HEARTBEAT parameter. When this match occurs, the address >> that the original HEARTBEAT was sent to is now considered >> CONFIRMED and available for normal data transfer. >> >> These probing proceedures are started when an association >> moves to the ESTABLISHED state and are ended when all >> paths are confirmed. >> >> Each RTO a probe may be sent on an active UNCONFIRMED path >> in an attempt to move it to to the CONFIRMED state. >> If during this probing the path becomes inactive this rate >> is lowered to the normal HEARTBEAT rate. At the expiration >> of the RTO timer the error counter of any path that was >> probed but not CONFIRMED is incremented by one and subjected >> to path failure detection defined in section 8.2. When probing >> UNCONFIRMED addresses, however, the association overall error count >> is NOT incremented. >> >> The number of HEARTBEATS sent at each RTO SHOULD be limited >> by the HB.Max.Burst parameter. It is an implementation decision >> as to how to distribute HEARTBEATS to the peers addresses >> for path verification. >> >> Whenever a path is confirmed an indication MAY be given to >> to the upper layer. >> >> An endpoint MUST NOT send any chunks to an UNCONFIRMED >> address with the following exceptions: >> >> - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED >> address. >> >> - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address. >> >> - A COOKIE-ACK MAY be sent to an UNCONFIRMED address but >> it MUST be bundled with a HEARTBEAT including a nonce. >> An implementation that does NOT support bundling MUST >> NOT send a COOKIE-ACK to an UNCONFIRMED address. >> >> - A COOKE-ECHO MAY be sent to an UNCONFIRMED address but >> it MUST be bundled with a HEARTBEAT including a nonce >> and the packet MUST NOT exceed the path MTU. If the >> implementation does NOT support bundling or the bundled >> COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed >> the path MTU, then the implemenation MUST NOT send >> a COOKIE-ECHO to an UNCONFIRMED address. >> >> ************************************************************* >> With the corresponding parameter defaults as follows: >> ************************************************************* >> The following protocol parameters are RECOMMENDED: >> >> RTO.Initial - 3 seconds >> RTO.Min - 1 second >> RTO.Max - 60 seconds >> Max.Burst - 4 >> RTO.Alpha - 1/8 >> RTO.Beta - 1/4 >> Valid.Cookie.Life - 60 seconds >> Association.Max.Retrans - 10 attempts >> Path.Max.Retrans - 5 attempts (per destination address) >> Max.Init.Retransmits - 8 attempts >> HB.Interval - 30 seconds >> HB.Max.Burst - 1 >> >> **************************************************************** >> >> >> I think this covers all that we had talked about... the byte >> amplification of INIT-ACK is mentioned/noted and I think >> we should move on... Implementations can minimize there >> INIT-ACK's as they deem appropriate and are now allowed >> to omit errors... >> >> Note, commens and suggested changes, as always, are most >> welcome :-D >> >> R >> >> -- >> Randall Stewart >> 803-345-0369 815-342-5222(cell) >> >> >> > > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 20 07:30:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYch-0006Ak-Em; Thu, 20 Oct 2005 07:30:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYce-0006AX-MB for tsvwg@megatron.ietf.org; Thu, 20 Oct 2005 07:30:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03441 for ; Thu, 20 Oct 2005 07:30:02 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESYoa-0004Yc-6h for tsvwg@ietf.org; Thu, 20 Oct 2005 07:42:32 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j9KBU9Q5023350; Thu, 20 Oct 2005 07:30:09 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <43577FC1.9000506@stewart.chicago.il.us> Date: Thu, 20 Oct 2005 07:30:09 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Tsvwg] ICMP issue with SCTP IG References: <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> <20051012173213.D29834@openss7.org> <19f654a1cac7d6c70ff1794cc1d16d21@lurchi.franken.de> <20051013021112.A8132@openss7.org> <84B66FE5-5CF2-4E4E-B5E0-A13F93CF7F4D@lurchi.franken.de> <20051013120547.L13555@openss7.org> <434ECB6A.20100@stewart.chicago.il.us> <20051013165407.A16196@openss7.org> In-Reply-To: <20051013165407.A16196@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Brian F. G. Bidulock wrote: > Randall, > > On Thu, 13 Oct 2005, Randall Stewart wrote: > > >>Brian F. G. Bidulock wrote: >> >> >>>>If an endpoint/middlebox want to say that a particular port number >>>>is not reachable it should use ABORT instead of ICMP(port unreachable). >>> >>> >>>I don't think the SCTP specification (transport) should place requirements >>>on what the network layer should or should not send. >>> >> >>I think the router requirments document already does this.. and I >>don't remember anything in the I-G that requires a middlebox >>to send anything.. if there is please point it out to me since >>we should get rid of it.. >> > > > No there was nothing in the document... Michael was arguing, I believe, > that a non-SCTP aware host or router would not generate ICMP(port > unreachable), but rather generate ICMP(prototcol unreachable), and an > SCTP aware host or router would generate ABORT instead of ICMP(port > unreachable), and concluding that ICMP(port unreachable) should be > ignored when received by an SCTP capable node. ahh.. > > My point was that the I-G does not (and should not) dictate when > ICMP(port unreachable) is to be sent, or for what reasons. That is, > indeed, up to the router requirements RFC to dictate. I agree.. the router requirements and I think to a lesser degree host requirements already covers port unreachable... > > An SCTP implementation receiving ICMP(port unreachable) should not be > required by the uncomping SCTP RFC to discard the messages, as in > accordance with the router requirements, they may indicate to the > sending SCTP that it can take action with regard to an association > in the absense of an ABORT that the router is no longer required to > send. > > Perhaps the receiving SCTP host should indeed process ICMP(port > unreachable) rather than being required to discard it as Michael > originally proposed. hmm.. that is a good point... but I wonder in reality how many port-unreachable messages are ever generated... for tcp I bet most send back a RST.. But no matter.. it does not hurt to have the processing in place for this.. since we CAN verify the V-tag ... R > > --brian > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 20 07:33:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYfO-0007w3-SJ; Thu, 20 Oct 2005 07:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYfM-0007tZ-Hp for tsvwg@megatron.ietf.org; Thu, 20 Oct 2005 07:33:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03748 for ; Thu, 20 Oct 2005 07:32:51 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESYrH-0004gk-8G for tsvwg@ietf.org; Thu, 20 Oct 2005 07:45:20 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j9KBWuQ5023361; Thu, 20 Oct 2005 07:32:56 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <43578068.1040107@stewart.chicago.il.us> Date: Thu, 20 Oct 2005 07:32:56 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] ICMP issue with SCTP IG References: <4346A997.5070300@stewart.chicago.il.us> <0C962C66-59C6-47E2-8A26-502D7E2413BF@lurchi.franken.de> <20051012173213.D29834@openss7.org> <19f654a1cac7d6c70ff1794cc1d16d21@lurchi.franken.de> <20051013021112.A8132@openss7.org> <84B66FE5-5CF2-4E4E-B5E0-A13F93CF7F4D@lurchi.franken.de> <20051013120547.L13555@openss7.org> <434ECB6A.20100@stewart.chicago.il.us> <20051013165407.A16196@openss7.org> <71E413A4-AE56-44AF-8E7B-7BEC6601F7C7@lurchi.franken.de> <20051014150447.C31640@openss7.org> <885F8670-4710-4828-9032-221E1B9BECCD@lurchi.franken.de> In-Reply-To: <885F8670-4710-4828-9032-221E1B9BECCD@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by stewart.chicago.il.us id j9KBWuQ5023361 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: bidulock@openss7.org, tsvwg@ietf.org, Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael: I have heard Fred Baker discuss the making of both requirements documents... and if I remember his phrasing right.. " it was a magic moment that cannot now be duplicated".. And I think he is right.. I would very much doubt we will ever see the requirments documents ever opened up.. if you think SCTPbis is tough.. I can't even imagine how hard a host or router requirements bis would be.. :-) R Michael Tuexen wrote: > Brian, >=20 > as far as I know there is noone working on a new version of RFC 1122. = And > I do not see, that it is necessary. > So what do you think about the text I suggested? >=20 > Best regards > Michael >=20 > On Oct 14, 2005, at 11:04 PM, Brian F. G. Bidulock wrote: >=20 >> Michael, >> >> I would prefer if any necessary changes were made in RFC 1122. That = is >> under the same WG is it not? >> >> --brian >> >> On Fri, 14 Oct 2005, Michael Tuexen wrote: >> >> >>> Dear all, >>> >>> my point is just to harmonize RFC 1122, Host Requirements, and the >>> future >>> SCTP specification. >>> >>> RFC 1122 states: >>> - An endpoint SHOULD delete the association on reception of an >>> ICMP(protocol unreachable). >>> - An endpoint MUST process an ICMP(port unreachable) like an >>> ABORT. >>> >>> The first would require a change from MUST to SHOULD as indicated >>> in my original mail. Currently the IG says that you must ignore >>> ICMP(port unreachable). I do not want to change anything regarding >>> the sending of this ICMP message, I'm only wondering if we should al= so >>> change the IG or (what I would prefer) to not change the IG on the >>> ICMP(port unreachable) processing and stating that this is a differe= nce >>> to RFC 1122. >>> >>> Best regards >>> Michael >>> >>> >> >> --=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 >> >> >=20 >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg >=20 >=20 >=20 --=20 Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 20 07:33:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYfZ-00080i-KB; Thu, 20 Oct 2005 07:33:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYfY-00080W-FO for tsvwg@megatron.ietf.org; Thu, 20 Oct 2005 07:33:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03757 for ; Thu, 20 Oct 2005 07:33:02 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESYrU-0004gs-4X for tsvwg@ietf.org; Thu, 20 Oct 2005 07:45:32 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j9KBWrY1031951; Thu, 20 Oct 2005 13:32:53 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9KBWrWp011393; Thu, 20 Oct 2005 13:32:53 +0200 Received: from MCHP7I6A.ww002.siemens.net ([139.25.131.137]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Oct 2005 13:32:53 +0200 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [Tsvwg] ICMP issue with SCTP IG Date: Thu, 20 Oct 2005 13:32:52 +0200 Message-ID: Thread-Topic: AW: [Tsvwg] ICMP issue with SCTP IG Thread-Index: AcXVaQMdlKBPMl6hQ2SETzRVB/eOrwAAJKWw From: "Meyknecht, Bernward" To: "Randall Stewart" X-OriginalArrivalTime: 20 Oct 2005 11:32:53.0226 (UTC) FILETIME=[02545CA0:01C5D56A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: bidulock@openss7.org, tsvwg@ietf.org, Michael Tuexen , Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org =20 Hi Randy, meanwhile I agree with Michael and with his new text, written after=20 my email from below, his new text is fine for me. Bernie -----Urspr=FCngliche Nachricht----- Von: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] Im Auftrag = von Randall Stewart Gesendet: Donnerstag, 20. Oktober 2005 13:24 An: Meyknecht, Bernward Cc: bidulock@openss7.org; tsvwg@ietf.org; Coene, Lode; Vlad Yasevich; = Michael Tuexen; Schruefer, Wolfgang; Kacheong Poon; Scott Bradner Betreff: Re: AW: [Tsvwg] ICMP issue with SCTP IG Bernward: I agree with Michael and Brian.. and I think most all the other developers that have not chimed in here objecting (I think you are alone in objecting to the must).. This is a MUST R Meyknecht, Bernward wrote: > =20 > Hi all, >=20 > I'm not content with the new section on ICMP handling for the SCTP IG, = incl.=20 > the 'MUST' for ICMP handling within an SCTP specification, and propose = to replace=20 > it by a weaker wording and moving the section to another place. >=20 > I would of course never propose to delete the ICMP section from the = IG, but for me=20 > it is something to be described in an appendix of the SCTP = specification, as it is=20 > done in the actual issue 15 of the IG, without the wording 'MUST', but = with=20 > something like '...should be followed to assure proper utilization of = the information=20 > being provided by layer 3', which is the current wording. >=20 > Adding ICMP handling to SCTP was motivated by attack scenarios = described in the=20 > draft draft-stewart-tsvwg-sctpthreat-03.txt, okay. > But the other enhancements being described for SCTP within the new IG = section,=20 > i.e. amplification control, path verification (small hb.max.burst) and = aborting=20 > when receiving an ack for an unsent TSN, etc. > these are exactlay the counter measures taken on SCTP level to prevent = the=20 > attacks. Besides that there is a number of circumstances on which the = attacks=20 > depend, i.e. which are necessary to allow the attack at all. > With an SCTP implementation having the SCTP enhancements as mentioned = above I=20 > don't see the relevance of these attacks on SCTP any more. >=20 > Besides that I see ICMP as something belonging to a layer below SCTP, = the SCTP=20 > RFC should describe only the SCTP level, hints on ICMP handling could = be part > of an extra document/draft, even in a future RFC. >=20 > Kind regards, --=20 Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ 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 tsvwg-bounces@ietf.org Thu Oct 20 08:14:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESZJS-0000II-TN; Thu, 20 Oct 2005 08:14:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESZJQ-0000ID-N3 for tsvwg@megatron.ietf.org; Thu, 20 Oct 2005 08:14:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07103 for ; Thu, 20 Oct 2005 08:14:14 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESZVL-0006M8-Tk for tsvwg@ietf.org; Thu, 20 Oct 2005 08:26:45 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j9KCEKQ5023528; Thu, 20 Oct 2005 08:14:21 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <43578A1C.1060905@stewart.chicago.il.us> Date: Thu, 20 Oct 2005 08:14:20 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Meyknecht, Bernward" Subject: Re: AW: AW: [Tsvwg] ICMP issue with SCTP IG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: bidulock@openss7.org, tsvwg@ietf.org, "Coene, Lode" , Vlad Yasevich , Michael Tuexen , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Meyknecht, Bernward wrote: > > Hi Randy, > > meanwhile I agree with Michael and with his new text, written after > my email from below, his new text is fine for me. > > Bernie > As long as you understand that you MUST process ICMP... Even 1122 makes this a MUST: Receiving ICMP Messages from IP |4.2.3.9 |x| | | | | Dest. Unreach (0,1,5) => inform ALP |4.2.3.9 | |x| | | | Dest. Unreach (0,1,5) => abort conn |4.2.3.9 | | | | |x| Dest. Unreach (2-4) => abort conn |4.2.3.9 | |x| | | | Source Quench => slow start |4.2.3.9 | |x| | | | Time Exceeded => tell ALP, don't abort |4.2.3.9 | |x| | | | Param Problem => tell ALP, don't abort |4.2.3.9 | |x| | | | ^ | This is the MUST colum... and note Receiving ICMP msg's is a MUST. Now how to handle is a LOT of SHOULDs.. but I have an issue with this.. and I will post it seperate... with a special add on of Bob Braden.. and a few others... R -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 20 08:37:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESZfJ-0000iw-1d; Thu, 20 Oct 2005 08:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESZfH-0000ir-8O for tsvwg@megatron.ietf.org; Thu, 20 Oct 2005 08:36:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08087 for ; Thu, 20 Oct 2005 08:36:49 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESZrD-0006vA-BX for tsvwg@ietf.org; Thu, 20 Oct 2005 08:49:20 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j9KCanQ5023598; Thu, 20 Oct 2005 08:36:51 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <43578F61.3070805@stewart.chicago.il.us> Date: Thu, 20 Oct 2005 08:36:49 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: TSWG , Bob Braden , Fred Baker , ekr@networkresonance.com, jon.peterson@neustar.biz, Allison Mankin , "James M. Polk" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: Subject: [Tsvwg] ICMP handling with SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org All: Ok, I have once again re-drafted the ICMP handling text for SCTP's I-G. Now, for those others of you on the to list you are wondering.. why is this email addressed to me... well its because I think there is yet one issue that we have not obtained closure on and it is IMO a security one... (thats why you are on here Eric) and it also deals with RFC1122 (Bob/Fred thats why you got added). The chairs to the tsv are also added.. since this is there wg and I think a chair response (and possibly an AD response is also warrented :-d) So at the bottom of this email I will attached the "updated" wording to the SCTP ICMP handling section of the I-G.. for those of you following you will see it is only slightly tweaked.. The hot issue is the MUST's used in ICMP8. For the new folks added that I KNOW have not been following this long thread.. let me try to summarize the issue. RFC1122 specifies that TCP SHOULD observer a protocol unreachable message and abort the connection. But in SCTP's case we have been debating between a MUST and a SHOULD.. so why? Consider this scheme (detailed in the sctp-threats document): Evil-A Server-Z (owns IP-A only) (owns IP-Z) -------INIT(IP-A, IP-1, IP-2, IP-3)------> <... rest of 4-way handshake..> Now if IP-1/2 and 3 are owned by hosts that DO NOT understand SCTP.. there are various schemes (I won't go in to.. you can look at these in draft-stewart-tsvwg-sctpthreat-xx.txt if you want) that you can get Server-Z to bombard and amplify data to IP-1/2 and 3. If, however, Server-Z's stack observes the ICMP messages as detailed below.. and we do have a MUST.. then the first HB (or any msg for that matter) that sends back a ICMP protocol Unreachable will kill the association thus foiling the evil attackers schemes :-D. This is quite a bit different than TCP in that TCP could only effect the source IP address of the SYN.. where as SCTP can stuff all these other IP addresses in place... So IMO handling a Protocol Unreachable really reaches the level of MUST abort.. not SHOULD abort... But there-in lies the problem.. this is different than what RFC-1122 does.. and since it is different we have a running SHOULD/MUST debate.. that I am looking for your wisdom to help us decide.. Does this case warrent being more strict on an SCTP implementation? I think it does.. Thanks in advanced for your kind responses.. --------------------------------------------------- Now.. Here is the actual text for the wg.. Note that ICMP9 and ICMP8 were redundant (they were almost word-for-word identical.. so I collapsed them down). For Brian and others.. note I put a lot of MAY's in so that the only ICMP binding thing is 1) use the data in the ICMP msg to find the assoc 2) use the Vtag to validate that the ICMP is not forged 3) treat the protocol unreachable message as an ABORT. All others become just "MAY" ********************************************************* Whenever an ICMP message is received by an SCTP endpoint the following procedures MUST be followed to assure proper utilization of the information being provided by layer 3. ICMP1) An implementation MAY ignore all ICMPv4 messages where the type field is not set to "Destination Unreachable". ICMP2) An implementation MAY ignore all ICMPv6 messages where the type field is not "Destination Unreachable, "Parameter Problem" or "Packet Too Big". ICMP3) An implementation MAY ignore any ICMPv4 messages where the code does not indicate "Protocol Unreachable" or "Fragmentation Needed". ICMP4) An implementation MAY ignore all ICMPv6 messages of type "Parameter Problem" if the code is not "Unrecognized next header type encountered". ICMP5) An implementation MUST use the payload of the ICMP message (V4 or V6) to locate the association which sent the message that ICMP is responding to. If the association cannot be found, An implementation SHOULD ignore the ICMP message. ICMP6) An implementation MUST validate that the verification tag contained in the ICMP message matches the verification tag of the peer. If the verification tag is not 0 and does NOT match, discard the ICMP message. If it is 0 and the ICMP message contains enough bytes to verify that the chunk type is an INIT chunk and that the initiate tag matches the tag of the peer continue with ICMP7. If the ICMP message is too short or, the chunk type or the initiate tag does not match, silently discard the packet. ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 "Fragmentation Needed" an implemenation MAY process this information as defined for PATH MTU discovery. ICMP8) If the ICMP code is a "Unrecognized next header type encountered" or a "Protocol Unreachable" an implementation MUST treat this message as an abort with the T bit set if it does not contain an INIT chunk. If it does contain an INIT chunk and the association is in COOKIE-WAIT state, handle the ICMP message like an ABORT. ICMP9) If the ICMPv6 code is "Destination Unreachable" the implementation MAY mark the destination into the unreachable state or alternatively increment the path error counter. ************************************************************************* -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 20 17:32:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESi1H-0005Em-Kv; Thu, 20 Oct 2005 17:32:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESi0H-00045A-Tf for tsvwg@megatron.ietf.org; Thu, 20 Oct 2005 17:31:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05750 for ; Thu, 20 Oct 2005 17:14:06 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EShvs-0001bG-CW for tsvwg@ietf.org; Thu, 20 Oct 2005 17:26:41 -0400 Received: from [192.168.1.17] (p508F630C.dip.t-dialin.net [80.143.99.12]) by ilsa.franken.de (Postfix) with ESMTP id 0500B245D1; Thu, 20 Oct 2005 23:14:05 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <43578F61.3070805@stewart.chicago.il.us> References: <43578F61.3070805@stewart.chicago.il.us> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] ICMP handling with SCTP Date: Thu, 20 Oct 2005 23:13:05 +0200 To: Randall Stewart X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.2 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit Cc: Bob Braden , ekr@networkresonance.com, jon.peterson@neustar.biz, Allison Mankin , "James M. Polk" , Fred Baker , TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Dear all, RFC 1122 also says: A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose. Should this also be done by SCTP? As Randy already pointed out that he prefers a difference between the RFC 1122 handling and the SCTP Impl Guide, I also prefer to NOT follow RFC 1122 on ICMP(port unreachable)and use the handling for ICMP(port unreachable) as described by the ICMP rules below. However, I think adding a sentence making this difference clear would help the reader finding the text below and RFC 1122 contradicting each other. Best regards Michael On Oct 20, 2005, at 14:36 Uhr, Randall Stewart wrote: > All: > > Ok, I have once again re-drafted the ICMP handling text for SCTP's I-G. > Now, for those others of you on the to list you are wondering.. > why is this email addressed to me... well its because I think > there is yet one issue that we have not obtained closure on and > it is IMO a security one... (thats why you are on here Eric) and > it also deals with RFC1122 (Bob/Fred thats why you got added). The > chairs to the tsv are also added.. since this is there wg and I > think a chair response (and possibly an AD response is also > warrented :-d) > > So at the bottom of this email I will attached the "updated" wording > to the SCTP ICMP handling section of the I-G.. for those of you > following you will see it is only slightly tweaked.. The hot issue > is the MUST's used in ICMP8. For the new folks added that I KNOW > have not been following this long thread.. let me try to summarize the > issue. > > RFC1122 specifies that TCP SHOULD observer a protocol unreachable > message and abort the connection. But in SCTP's case we have > been debating between a MUST and a SHOULD.. so why? > > Consider this scheme (detailed in the sctp-threats document): > > Evil-A Server-Z > (owns IP-A only) (owns IP-Z) > > -------INIT(IP-A, IP-1, IP-2, IP-3)------> > <... rest of 4-way handshake..> > > Now if IP-1/2 and 3 are owned by hosts that DO NOT > understand SCTP.. there are various schemes (I won't > go in to.. you can look at these in > draft-stewart-tsvwg-sctpthreat-xx.txt if you want) > that you can get Server-Z to bombard and amplify data > to IP-1/2 and 3. > > If, however, Server-Z's stack observes the ICMP messages > as detailed below.. and we do have a MUST.. then the first > HB (or any msg for that matter) that sends back a ICMP protocol > Unreachable will kill the association thus foiling the > evil attackers schemes :-D. > > This is quite a bit different than TCP in that TCP could only > effect the source IP address of the SYN.. where as SCTP > can stuff all these other IP addresses in place... So > IMO handling a Protocol Unreachable really reaches the > level of MUST abort.. not SHOULD abort... > > But there-in lies the problem.. this is different than what > RFC-1122 does.. and since it is different we have a running > SHOULD/MUST debate.. that I am looking for your wisdom to > help us decide.. > > Does this case warrent being more strict on an SCTP implementation? > > I think it does.. > > Thanks in advanced for your kind responses.. > --------------------------------------------------- > Now.. Here is the actual text for the wg.. Note that ICMP9 and ICMP8 > were redundant (they were almost word-for-word identical.. so I > collapsed them down). > > For Brian and others.. note I put a lot of MAY's in so that > the only ICMP binding thing is > 1) use the data in the ICMP msg to find the assoc > 2) use the Vtag to validate that the ICMP is not forged > 3) treat the protocol unreachable message as an ABORT. > > All others become just "MAY" > > ********************************************************* > Whenever an ICMP message is received by an SCTP endpoint the > following procedures MUST be followed to assure proper > utilization of the information being provided by layer 3. > > ICMP1) An implementation MAY ignore all ICMPv4 messages > where the type field is not set to "Destination > Unreachable". > > ICMP2) An implementation MAY ignore all ICMPv6 messages > where the type field is not "Destination Unreachable, > "Parameter Problem" or "Packet Too Big". > > ICMP3) An implementation MAY ignore any ICMPv4 messages > where the code does not indicate "Protocol Unreachable" > or "Fragmentation Needed". > > ICMP4) An implementation MAY ignore all ICMPv6 messages > of type "Parameter Problem" if the code is not > "Unrecognized next header type encountered". > > ICMP5) An implementation MUST use the payload of the > ICMP message (V4 or V6) to locate the association > which sent the message that ICMP is responding to. > If the association cannot be found, An implementation SHOULD > ignore the ICMP message. > > ICMP6) An implementation MUST validate that the verification tag > contained in the ICMP message matches the verification > tag of the peer. If the verification tag is not 0 and does > NOT match, discard the ICMP message. If it is 0 and the > ICMP message contains enough bytes to verify that the chunk > type is an INIT chunk and that the initiate tag matches > the tag of the peer continue with ICMP7. If the ICMP > message is too short or, the chunk type or the > initiate tag does not match, silently discard the packet. > > ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 > "Fragmentation Needed" an implemenation MAY process this > information as defined for PATH MTU discovery. > > ICMP8) If the ICMP code is a "Unrecognized next header type > encountered" or a "Protocol Unreachable" an implementation > MUST treat this message as an abort with the T bit set > if it does not contain an INIT chunk. If it does contain > an INIT chunk and the association is in COOKIE-WAIT state, > handle the ICMP message like an ABORT. > > ICMP9) If the ICMPv6 code is "Destination Unreachable" the > implementation MAY mark the destination into the unreachable > state or alternatively increment the path error counter. > > *********************************************************************** > ** > > -- > Randall Stewart > 803-345-0369 815-342-5222(cell) > > _______________________________________________ > 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 tsvwg-bounces@ietf.org Thu Oct 20 19:45:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESk6h-0008UB-CW; Thu, 20 Oct 2005 19:45:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESk6c-0008Sh-Nk for tsvwg@megatron.ietf.org; Thu, 20 Oct 2005 19:45:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09505 for ; Thu, 20 Oct 2005 19:45:43 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[7ww1dhGR1F+SCSFN6EoIi9WF4/kYn18y]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESk7s-0004Hd-9G for tsvwg@ietf.org; Thu, 20 Oct 2005 19:47:13 -0400 Received: from ns.pigworks.openss7.net (IDENT:jtoaqaNdFtRHvtjexwoDGKZzwkygo2Qs@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j9KNY1c24062; Thu, 20 Oct 2005 17:34:01 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j9KNXx011589; Thu, 20 Oct 2005 17:33:59 -0600 Date: Thu, 20 Oct 2005 17:33:59 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Subject: Re: [Tsvwg] ICMP issue with SCTP IG Message-ID: <20051020173359.B10778@openss7.org> References: <28d6f7b73746b7bbe5b706a75222ce50@lurchi.franken.de> <20050922045114.B6756@openss7.org> <69d50fe7d87f21c6298f1f561145c166@lurchi.franken.de> <20050923033810.B18747@openss7.org> <433829E2.4060807@stewart.chicago.il.us> <4e220c915568d9fcd12a54f6e3376194@lurchi.franken.de> <4346A997.5070300@stewart.chicago.il.us> <20051011163216.A12351@openss7.org> <43577C82.2060205@stewart.chicago.il.us> 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: <43577C82.2060205@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Thu, Oct 20, 2005 at 07:16:18AM -0400 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 j9KNY1c24062 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, Michael Tuexen , Vlad Yasevich , "Coene, Lode" , "Schruefer, Wolfgang" , Kacheong Poon , Scott Bradner X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Randall, I'll conceded DATA with COOKIE-ACK. If the receiver of the COOKIE-ECHO needs to send DATA with COOKIE-ACK, I suppose it will just have to be to the origin of the COOKIE-ECHO (the only verified address). The others were handled by your new text, except the last one. Why would an association need to persist more at initialization and verification than it does during normal operation? I still don't see why we would not peg error counts just because we are verifying. If we sent simply HEARTBEATs (which I understand some implementations do of the bat anyway) we would peg counts. If we were sending HEARTBEATS due to inactivity, we should peg counts. Also, if the user does not wish associations brought down when only, say, 5 out of 6 destinations are unreachable, why did they set the path max retrans and association max retrans to do so? And if the user sets them to fail the association when 5 out of 6 destinations are unreachable, why would we not do so regardless of whether it is the normal or verification phases? --brian --=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 tsvwg-bounces@ietf.org Thu Oct 20 19:49:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESk9s-0001cH-0q; Thu, 20 Oct 2005 19:49:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESk6b-0008Ru-2n for tsvwg@megatron.ietf.org; Thu, 20 Oct 2005 19:45:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09485 for ; Thu, 20 Oct 2005 19:45:41 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[aRll+qsSnQ8uIhWJWQPpbHqAxpQQ/Zxi]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESk8J-0004UD-Ic for tsvwg@ietf.org; Thu, 20 Oct 2005 19:47:40 -0400 Received: from ns.pigworks.openss7.net (IDENT:yvsLzwd+Yy9E+7nNYyOmNZyFw7jAN16g@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j9KNZ6c24080; Thu, 20 Oct 2005 17:35:06 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j9KNZ2l11603; Thu, 20 Oct 2005 17:35:02 -0600 Date: Thu, 20 Oct 2005 17:35:02 -0600 From: "Brian F. G. Bidulock" To: Michael Tuexen Subject: Re: [Tsvwg] ICMP handling with SCTP Message-ID: <20051020173502.C10778@openss7.org> References: <43578F61.3070805@stewart.chicago.il.us> 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: ; from Michael.Tuexen@lurchi.franken.de on Thu, Oct 20, 2005 at 11:13:05PM +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 j9KNZ6c24080 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: TSWG , Bob Braden , ekr@networkresonance.com, jon.peterson@neustar.biz, Allison Mankin , "James M. Polk" , Randall Stewart , Fred Baker X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Michael, I agree, the distinction should be highlighted. --brian On Thu, 20 Oct 2005, Michael Tuexen wrote: > Dear all, >=20 > RFC 1122 also says: >=20 > A transport protocol > that has its own mechanism for notifying the sender that a > port is unreachable (e.g., TCP, which sends RST segments) > MUST nevertheless accept an ICMP Port Unreachable for the > same purpose. >=20 > Should this also be done by SCTP? As Randy already pointed out that he > prefers a difference between the RFC 1122 handling and the SCTP Impl =20 > Guide, > I also prefer to NOT follow RFC 1122 on ICMP(port unreachable)and use =20 > the > handling for ICMP(port unreachable) as described by the ICMP rules =20 > below. > However, I think adding a sentence making this difference clear would =20 > help the > reader finding the text below and RFC 1122 contradicting each other. >=20 > Best regards > Michael >=20 --=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 tsvwg-bounces@ietf.org Fri Oct 21 10:17:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxi4-0003Nj-OJ; Fri, 21 Oct 2005 10:17:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxi0-0003CP-I6 for tsvwg@megatron.ietf.org; Fri, 21 Oct 2005 10:17:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24089 for ; Fri, 21 Oct 2005 10:17:13 -0400 (EDT) Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESxu5-0002cL-20 for tsvwg@ietf.org; Fri, 21 Oct 2005 10:29:58 -0400 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 15:16:54 +0100 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 15:16:54 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 15:16:54 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1129904210616; Fri, 21 Oct 2005 15:16:50 +0100 Received: from mut.jungle.bt.co.uk ([10.86.16.41]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id j9LEGTDr000938; Fri, 21 Oct 2005 15:16:41 +0100 Message-Id: <5.2.1.1.2.20051021150608.02852628@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 21 Oct 2005 15:16:14 +0100 To: tsvwg@ietf.org From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Oct 2005 14:16:54.0966 (UTC) FILETIME=[16E07560:01C5D64A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nspring@cs.washington.edu Subject: [Tsvwg] New draft: Re-ECN: Adding Accountability for Causing Congestion to TCP/IP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org tsvwg, I've uploaded a new draft for consideration by tsvwg. It's the one Allison Mankin asked me to do in Paris, giving our alternative proposal for the use of the ECN nonce codepoints in the IP header: Below are the citation details with a link to HTML format etc, and a note on why we are posting this now. =========================================================================== Re-ECN: Adding Accountability for Causing Congestion to TCP/IP, Bob Briscoe (BT & UCL), Arnaud Jacquet and Alessandro Salvatori (BT), IETF Internet-Draft draft-briscoe-tsvwg-re-ecn-tcp-00.html (Oct 2005). (27pp, 10 refs, 5 figs) Abstract: This document introduces a new feedback protocol for explicit congestion notification (ECN), termed re-ECN. It arranges the ECN field of each packet so that, as it arrives at each router, the relative rates of each codepoint will give a truthful prediction of congestion on the remainder of the path. It also outlines mechanisms at the network edge that ensure the dominant selfish strategy of both network domains and end-points will be to set these codepoints honestly and to respond correctly to path congestion, despite conflicting interests. Although these mechanisms influence incentives, they use engineering mechanisms like throttling and dropping, rather than requiring changes to end-user pricing. The protocol can be deployed incrementally around unmodified routers without requiring changes to IP. Authors' Statement: Status This document is posted as an initial Internet-Draft with the intent (at least that of the authors) to eventually progress to standards track. However, it proposes using the ECN codepoints currently set aside for the experimental ECN nonce. The protocol proposed here aims to allow networks to be able to police cheating senders and receivers and to police neighbouring networks. On the other hand, the ECN nonce aims to allow senders to detect cheating receivers. Although the proposed scheme addresses a much more pressing problem, compromises in its strength have had to be introduced in order to make it incrementally deployable. We therefore seek the opinion of the Internet Community on whether the resulting strength is sufficient to warrant standards action. Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 21 15:14:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2Ly-0005td-5Y; Fri, 21 Oct 2005 15:14:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2Lw-0005sT-IE for tsvwg@megatron.ietf.org; Fri, 21 Oct 2005 15:14:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27389 for ; Fri, 21 Oct 2005 15:14:45 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET2Y6-0002qs-RK for tsvwg@ietf.org; Fri, 21 Oct 2005 15:27:33 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9LJDgL02152; Fri, 21 Oct 2005 12:13:42 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id MAA10469; Fri, 21 Oct 2005 12:13:41 -0700 (PDT) Date: Fri, 21 Oct 2005 12:13:41 -0700 (PDT) Message-Id: <200510211913.MAA10469@gra.isi.edu> To: tsvwg@ietf.org, braden@ISI.EDU, fred@cisco.com, ekr@networkresonance.com, jon.peterson@neustar.biz, mankin@psg.com, jmpolk@cisco.com, randall@stewart.chicago.il.us Subject: Re: [Tsvwg] ICMP handling with SCTP X-Sun-Charset: US-ASCII X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org *> *> But there-in lies the problem.. this is different than what *> RFC-1122 does.. and since it is different we have a running *> SHOULD/MUST debate.. that I am looking for your wisdom to *> help us decide.. Two points: First, in many cases the MUST/SHOULD decisions in RFC 1122,3 were a bit fluffy. The general intent of the Host Requirements RFCs was to stem the tide of an increasing number of sloppy or deliberately substandard implementations of the protocols, by requiring that every host implementation actually support (all) the protocol features. Those features were there for a reason and had been adopted after careful consideration. The IETF community of that day (1988) did not take kindly to individual host software implementors who thought they "knew better". But the 50 or so IETFers who contributed to the HR RFCs had varying degrees of certainty about various features, and that often led to backing off from MUST to SHOULD. (Of course, there were also cases where there were specific, carefully-considered reasons for a MUST/SHOULD choice). So there was a certain amount of educated techie intuition at work here. The second point follows from the first. If a new transport protocol has specific reasons for being MORE restrictive than RFC 1122, that seems to be consonant with the general intent of RFC 1122. I would like to point out one other feature of the HR RFCs: we tried really hard to put down explanations for decisions, to avoid endless future arguments. So, it would also be in the spirit of RFC 1122 if your documentation noted the diference and said why. Probably 1-2 sentences are enough here; no long treatise is necessary/desirable. (I always liked the indented DISCUSSION paragraphs that we invented for the HR RFCs; I think it is too bad that this documentation approach has not been emulated by other IETF protocol specification documents.) BTW, it seems a little strange to me to say "...following procedures MUST be followed .." when the procedures themselves often contain MAY. This seems like an overuse of MUST. IETFers seem to have trouble with this concept, but it is really OK to use the word "must" without capitalization in an RFC! Bob Braden *> *> Does this case warrent being more strict on an SCTP implementation? *> *> I think it does.. *> *> Thanks in advanced for your kind responses.. *> --------------------------------------------------- *> Now.. Here is the actual text for the wg.. Note that ICMP9 and ICMP8 *> were redundant (they were almost word-for-word identical.. so I *> collapsed them down). *> *> For Brian and others.. note I put a lot of MAY's in so that *> the only ICMP binding thing is *> 1) use the data in the ICMP msg to find the assoc *> 2) use the Vtag to validate that the ICMP is not forged *> 3) treat the protocol unreachable message as an ABORT. *> *> All others become just "MAY" *> *> ********************************************************* *> Whenever an ICMP message is received by an SCTP endpoint the *> following procedures MUST be followed to assure proper *> utilization of the information being provided by layer 3. *> *> ICMP1) An implementation MAY ignore all ICMPv4 messages *> where the type field is not set to "Destination *> Unreachable". *> *> ICMP2) An implementation MAY ignore all ICMPv6 messages *> where the type field is not "Destination Unreachable, *> "Parameter Problem" or "Packet Too Big". *> *> ICMP3) An implementation MAY ignore any ICMPv4 messages *> where the code does not indicate "Protocol Unreachable" *> or "Fragmentation Needed". *> *> ICMP4) An implementation MAY ignore all ICMPv6 messages *> of type "Parameter Problem" if the code is not *> "Unrecognized next header type encountered". *> *> ICMP5) An implementation MUST use the payload of the *> ICMP message (V4 or V6) to locate the association *> which sent the message that ICMP is responding to. *> If the association cannot be found, An implementation SHOULD *> ignore the ICMP message. *> *> ICMP6) An implementation MUST validate that the verification tag *> contained in the ICMP message matches the verification *> tag of the peer. If the verification tag is not 0 and does *> NOT match, discard the ICMP message. If it is 0 and the *> ICMP message contains enough bytes to verify that the chunk *> type is an INIT chunk and that the initiate tag matches *> the tag of the peer continue with ICMP7. If the ICMP *> message is too short or, the chunk type or the *> initiate tag does not match, silently discard the packet. *> *> ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 *> "Fragmentation Needed" an implemenation MAY process this *> information as defined for PATH MTU discovery. *> *> ICMP8) If the ICMP code is a "Unrecognized next header type *> encountered" or a "Protocol Unreachable" an implementation *> MUST treat this message as an abort with the T bit set *> if it does not contain an INIT chunk. If it does contain *> an INIT chunk and the association is in COOKIE-WAIT state, *> handle the ICMP message like an ABORT. *> *> ICMP9) If the ICMPv6 code is "Destination Unreachable" the *> implementation MAY mark the destination into the unreachable *> state or alternatively increment the path error counter. *> *> ************************************************************************* *> *> -- *> Randall Stewart *> 803-345-0369 815-342-5222(cell) *> *> _______________________________________________ *> 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 tsvwg-bounces@ietf.org Fri Oct 21 15:23:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2UC-0004XG-UC; Fri, 21 Oct 2005 15:23:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2UB-0004VW-Fz for tsvwg@megatron.ietf.org; Fri, 21 Oct 2005 15:23:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28053 for ; Fri, 21 Oct 2005 15:23:16 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET2gN-0003GV-PL for tsvwg@ietf.org; Fri, 21 Oct 2005 15:36:04 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9LJMCL04991; Fri, 21 Oct 2005 12:22:12 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id MAA10493; Fri, 21 Oct 2005 12:22:11 -0700 (PDT) Date: Fri, 21 Oct 2005 12:22:11 -0700 (PDT) Message-Id: <200510211922.MAA10493@gra.isi.edu> To: tsvwg@ietf.org, braden@ISI.EDU, fred@cisco.com, ekr@networkresonance.com, jon.peterson@neustar.biz, mankin@psg.com, jmpolk@cisco.com, randall@stewart.chicago.il.us Subject: Re: [Tsvwg] ICMP handling with SCTP X-Sun-Charset: US-ASCII X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org One other thought: I think it is marvelous that someone is checking their new protocol spec for consistency with the Host Requirements RFCs. That reflects a degree of care and maturity that seems less common than one could wish, in the IETF of today. Bob Braden _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 21 15:40:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2l7-00089Y-0J; Fri, 21 Oct 2005 15:40:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESKK0-0005V6-Vb for tsvwg@megatron.ietf.org; Wed, 19 Oct 2005 16:14:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16423 for ; Wed, 19 Oct 2005 16:13:50 -0400 (EDT) Received: from mclean-vscan2.bah.com ([156.80.3.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESKVl-0000zZ-Bp for tsvwg@ietf.org; Wed, 19 Oct 2005 16:26:12 -0400 Received: from mclean-vscan2.bah.com (mclean-vscan2.bah.com [156.80.3.62]) by mclean-vscan2.bah.com (8.11.0/8.11.0) with SMTP id j9JKDZ507566; Wed, 19 Oct 2005 16:13:35 -0400 (EDT) Received: from mclnexbh03.resource.ds.bah.com ([156.80.7.153]) by mclean-vscan2.bah.com (SAVSMTP 3.1.7.47) with SMTP id M2005101916133425012 ; Wed, 19 Oct 2005 16:13:34 -0400 Received: from MCLNEXVS11.resource.ds.bah.com ([156.80.7.215]) by mclnexbh03.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 16:13:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2005 16:13:35 -0400 Message-ID: Thread-Topic: WG Last Call on draft-tsvwg-rsvp-dste-00.txt Thread-Index: AcXAHxBHCLGnoXNqRcqN2ojBoX1cagPHZmqQATEqhiAAMGi1UA== From: "Davenport Michael" To: "Francois Le Faucheur \(flefauch\)" , , "Jon Peterson" X-OriginalArrivalTime: 19 Oct 2005 20:13:37.0258 (UTC) FILETIME=[96CF8CA0:01C5D4E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 21 Oct 2005 15:40:55 -0400 Cc: gash@att.com, tsvwg@ietf.org, Christou Chris Subject: [Tsvwg] RE: WG Last Call on draft-tsvwg-rsvp-dste-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Greetings Allison and Jon, I would like to pop in support for the request for a WG Last Call on and hope you've had the chance to consider who the reviewers would be to comment in time for the discussion in Vancouver. Thanks... Mike =20 >> -----Original Message----- >> From: Francois Le Faucheur (flefauch) >> Sent: mercredi 12 octobre 2005 17:04 >> To: 'Allison Mankin'; 'Peterson, Jon' >> Cc: Bruce Davie (bdavie); 'Christou Chris'; 'Davenport Michael';=20 >> 'gash@att.com'; Francois Le Faucheur (flefauch); tsvwg@ietf.org >> Subject: WG Last Call on draft-tsvwg-rsvp-dste-00.txt >>=20 >> Hello Allison, Jon, >>=20 >> I understand the decision at last meeting was to issue a WG Last Call >> on and make sure that, as part of the=20 >> WGLC, at least a couple of "RSVP Team" >> members write up their reviews. >>=20 >> Could we go ahead with the LC? >>=20 >> Could you help identify who from the "RSVP Team" can commit to=20 >> written reviews? >>=20 >> That way we could work face to face in Vancouver to close potential=20 >> comments/issues from the review. >> =20 >> Thank you >> =20 >> Francois >> =20 >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> From draft minutes: >> " >> >> Allison said that she is willing to have a WGLC, but the WG needs=20 >> >> to have written reviews from the people that call themselves the=20 >> >> "RSVP team". >> >> Any objections? No one voiced objections. >> >>=20 >> >> Allson called for a hum: People supporting wglc at this time? >> >> There was moderate support Allison declares enough support to go=20 >> >> ahead. The requirement will be a least a couple of RSVP reviewers=20 >> >> (from the RSVP team) to write during WGLC. >> " >>=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 21 15:40:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2l7-00089x-Mf; Fri, 21 Oct 2005 15:40:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESdJR-0002rI-IC for tsvwg@megatron.ietf.org; Thu, 20 Oct 2005 12:30:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27742 for ; Thu, 20 Oct 2005 12:30:29 -0400 (EDT) Received: from mclean-vscan2.bah.com ([156.80.3.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESdVM-00089G-Hv for tsvwg@ietf.org; Thu, 20 Oct 2005 12:43:02 -0400 Received: from mclean-vscan2.bah.com (mclean-vscan2.bah.com [156.80.3.62]) by mclean-vscan2.bah.com (8.11.0/8.11.0) with SMTP id j9KGUF523201; Thu, 20 Oct 2005 12:30:15 -0400 (EDT) Received: from mclnexbh01.resource.ds.bah.com ([156.80.7.151]) by mclean-vscan2.bah.com (SAVSMTP 3.1.7.47) with SMTP id M2005102012301532186 ; Thu, 20 Oct 2005 12:30:15 -0400 Received: from MCLNEXVS12.resource.ds.bah.com ([156.80.7.217]) by mclnexbh01.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 12:30:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Oct 2005 12:30:15 -0400 Message-ID: <46E7B21EF4A45749B2432ABDCDE6FEA1176A8C@MCLNEXVS12.resource.ds.bah.com> Thread-Topic: WG Last Call on draft-tsvwg-rsvp-dste-00.txt Thread-Index: AcXAHxBHCLGnoXNqRcqN2ojBoX1cagPHZmqQAWjgYPA= From: "Christou Chris" To: "Francois Le Faucheur \(flefauch\)" , "Allison Mankin" , "Peterson, Jon" X-OriginalArrivalTime: 20 Oct 2005 16:30:14.0963 (UTC) FILETIME=[8CD56030:01C5D593] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 21 Oct 2005 15:40:55 -0400 Cc: tsvwg@ietf.org, gash@att.com Subject: [Tsvwg] RE: WG Last Call on draft-tsvwg-rsvp-dste-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org I would agree with the need for a LC--I think this draft is relatively mature and has applicability for many systems. As Francois points out, we could work in Vancouver towards resolving any final comments that would emanate from the review. Thanks, Chris =20 -----Original Message----- From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]=20 Sent: Wednesday, October 12, 2005 11:04 AM To: Allison Mankin; Peterson, Jon Cc: Bruce Davie (bdavie); Christou Chris; Davenport Michael; gash@att.com; Francois Le Faucheur (flefauch); tsvwg@ietf.org Subject: WG Last Call on draft-tsvwg-rsvp-dste-00.txt Hello Allison, Jon, I understand the decision at last meeting was to issue a WG Last Call on and make sure that, as part of the WGLC, at least a couple of "RSVP Team" members write up their reviews. Could we go ahead with the LC? Could you help identify who from the "RSVP Team" can commit to written reviews? That way we could work face to face in Vancouver to close potential comments/issues from the review. =20 Thank you =20 Francois =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >From draft minutes: " >> Allison said that she is willing to have a WGLC, but the WG needs to=20 >> have written reviews from the people that call themselves the "RSVP=20 >> team". >> Any objections? No one voiced objections. >>=20 >> Allson called for a hum: People supporting wglc at this time? >> There was moderate support Allison declares enough support to go=20 >> ahead. The requirement will be a least a couple of RSVP reviewers=20 >> (from the RSVP team) to write during WGLC. " _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 21 18:07:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET52f-0007xk-C4; Fri, 21 Oct 2005 18:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET52d-0007xT-RJ for tsvwg@megatron.ietf.org; Fri, 21 Oct 2005 18:07:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21096 for ; Fri, 21 Oct 2005 18:07:00 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET5Er-0008C5-FY for tsvwg@ietf.org; Fri, 21 Oct 2005 18:19:50 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j9LM76Q5034554; Fri, 21 Oct 2005 18:07:06 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <4359668A.9000104@stewart.chicago.il.us> Date: Fri, 21 Oct 2005 18:07:06 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Braden Subject: Re: [Tsvwg] ICMP handling with SCTP References: <200510211913.MAA10469@gra.isi.edu> In-Reply-To: <200510211913.MAA10469@gra.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit Cc: ekr@networkresonance.com, jon.peterson@neustar.biz, mankin@psg.com, jmpolk@cisco.com, fred@cisco.com, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Bob: Thanks for the response.. I really appreciate it.. A comment or two within.. Bob Braden wrote: > *> > *> But there-in lies the problem.. this is different than what > *> RFC-1122 does.. and since it is different we have a running > *> SHOULD/MUST debate.. that I am looking for your wisdom to > *> help us decide.. > > Two points: First, in many cases the MUST/SHOULD decisions in RFC > 1122,3 were a bit fluffy. The general intent of the Host Requirements > RFCs was to stem the tide of an increasing number of sloppy or > deliberately substandard implementations of the protocols, by requiring > that every host implementation actually support (all) the protocol features. > Those features were there for a reason and had been adopted after > careful consideration. The IETF community of that day (1988) did not > take kindly to individual host software implementors who thought they > "knew better". But the 50 or so IETFers who contributed to the HR > RFCs had varying degrees of certainty about various features, and > that often led to backing off from MUST to SHOULD. (Of course, there > were also cases where there were specific, carefully-considered > reasons for a MUST/SHOULD choice). So there was a certain amount > of educated techie intuition at work here. > > The second point follows from the first. If a new transport protocol > has specific reasons for being MORE restrictive than RFC 1122, that > seems to be consonant with the general intent of RFC 1122. > > I would like to point out one other feature of the HR RFCs: we tried > really hard to put down explanations for decisions, to avoid endless > future arguments. So, it would also be in the spirit of RFC 1122 if > your documentation noted the diference and said why. Probably 1-2 > sentences are enough here; no long treatise is necessary/desirable. (I > always liked the indented DISCUSSION paragraphs that we invented for > the HR RFCs; I think it is too bad that this documentation approach has > not been emulated by other IETF protocol specification documents.) > You know, I have read it several times and it never even struck me .. maybe this would be a good way to handle this note .. I do like the idea :-D > BTW, it seems a little strange to me to say "...following procedures > MUST be followed .." when the procedures themselves often contain MAY. > This seems like an overuse of MUST. IETFers seem to have trouble with > this concept, but it is really OK to use the word "must" without > capitalization in an RFC! Well.. that is a combination of me being lazy.. and the difficulty of finding a way to slip in the ICMP handling without being too disruptive to the orginal document... sigh.. We really probably need to haul this into the main document that way we don't have to have pointer from the security section to an appendix... I agree its kinda cheezy... Probably a whole section that introduces it.. then the ICMP rules.. and then the 2 sentence note telling how this difference from 1122... R > > Bob Braden > > > *> > *> Does this case warrent being more strict on an SCTP implementation? > *> > *> I think it does.. > *> > *> Thanks in advanced for your kind responses.. > *> --------------------------------------------------- > *> Now.. Here is the actual text for the wg.. Note that ICMP9 and ICMP8 > *> were redundant (they were almost word-for-word identical.. so I > *> collapsed them down). > *> > *> For Brian and others.. note I put a lot of MAY's in so that > *> the only ICMP binding thing is > *> 1) use the data in the ICMP msg to find the assoc > *> 2) use the Vtag to validate that the ICMP is not forged > *> 3) treat the protocol unreachable message as an ABORT. > *> > *> All others become just "MAY" > *> > *> ********************************************************* > *> Whenever an ICMP message is received by an SCTP endpoint the > *> following procedures MUST be followed to assure proper > *> utilization of the information being provided by layer 3. > *> > *> ICMP1) An implementation MAY ignore all ICMPv4 messages > *> where the type field is not set to "Destination > *> Unreachable". > *> > *> ICMP2) An implementation MAY ignore all ICMPv6 messages > *> where the type field is not "Destination Unreachable, > *> "Parameter Problem" or "Packet Too Big". > *> > *> ICMP3) An implementation MAY ignore any ICMPv4 messages > *> where the code does not indicate "Protocol Unreachable" > *> or "Fragmentation Needed". > *> > *> ICMP4) An implementation MAY ignore all ICMPv6 messages > *> of type "Parameter Problem" if the code is not > *> "Unrecognized next header type encountered". > *> > *> ICMP5) An implementation MUST use the payload of the > *> ICMP message (V4 or V6) to locate the association > *> which sent the message that ICMP is responding to. > *> If the association cannot be found, An implementation SHOULD > *> ignore the ICMP message. > *> > *> ICMP6) An implementation MUST validate that the verification tag > *> contained in the ICMP message matches the verification > *> tag of the peer. If the verification tag is not 0 and does > *> NOT match, discard the ICMP message. If it is 0 and the > *> ICMP message contains enough bytes to verify that the chunk > *> type is an INIT chunk and that the initiate tag matches > *> the tag of the peer continue with ICMP7. If the ICMP > *> message is too short or, the chunk type or the > *> initiate tag does not match, silently discard the packet. > *> > *> ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 > *> "Fragmentation Needed" an implemenation MAY process this > *> information as defined for PATH MTU discovery. > *> > *> ICMP8) If the ICMP code is a "Unrecognized next header type > *> encountered" or a "Protocol Unreachable" an implementation > *> MUST treat this message as an abort with the T bit set > *> if it does not contain an INIT chunk. If it does contain > *> an INIT chunk and the association is in COOKIE-WAIT state, > *> handle the ICMP message like an ABORT. > *> > *> ICMP9) If the ICMPv6 code is "Destination Unreachable" the > *> implementation MAY mark the destination into the unreachable > *> state or alternatively increment the path error counter. > *> > *> ************************************************************************* > *> > *> -- > *> Randall Stewart > *> 803-345-0369 815-342-5222(cell) > *> > *> _______________________________________________ > *> tsvwg mailing list > *> tsvwg@ietf.org > *> https://www1.ietf.org/mailman/listinfo/tsvwg > *> > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sat Oct 22 12:43:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETMSp-0006OU-AN; Sat, 22 Oct 2005 12:43:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETMSO-0006FS-45 for tsvwg@megatron.ietf.org; Sat, 22 Oct 2005 12:42:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19775 for ; Sat, 22 Oct 2005 12:42:43 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETMek-0005I6-Hv for tsvwg@ietf.org; Sat, 22 Oct 2005 12:55:43 -0400 Received: from [192.168.1.17] (p508F6660.dip.t-dialin.net [80.143.102.96]) by ilsa.franken.de (Postfix) with ESMTP id 8B77E245C5; Sat, 22 Oct 2005 18:42:31 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <200510211922.MAA10493@gra.isi.edu> References: <200510211922.MAA10493@gra.isi.edu> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] ICMP handling with SCTP Date: Sat, 22 Oct 2005 18:41:30 +0200 To: Bob Braden X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, jon.peterson@neustar.biz, mankin@psg.com, ekr@networkresonance.com, jmpolk@cisco.com, randall@stewart.chicago.il.us, fred@cisco.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi Bob, just a clarification from my side. I brought the stuff with the HR up. SCTP is in the focus of Telcos because it is originally developed for SS7/IP. And that brings companies and standards bodies on the plan which work on conformance testing. Unfortunately these guys have, lets say, only minor protocol understanding and are scanning the RFCs for MUST to derive a test case. They do not know how to handle differences between RFCs. That is why I wanted to harmonize them or state clearly in the SCTP RFC that there is a difference and it should be done like in the SCTP RFC. Thank you very much again for your clarification. Regarding the MUST/SHOULD I think the way to go is to enforce a MUST for SCTP stating the difference. We would be weaker on the ICMP(Port unreachable), I think, since currently no SCTP implementation I know of sends it and I would like to encourage people to keep it like it is. Best regards Michael On Oct 21, 2005, at 21:22 Uhr, Bob Braden wrote: > > One other thought: I think it is marvelous that someone is checking > their new protocol spec for consistency with the Host Requirements > RFCs. > That reflects a degree of care and maturity that seems less common than > one could wish, in the IETF of today. > > Bob Braden > > _______________________________________________ > 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 tsvwg-bounces@ietf.org Mon Oct 24 07:40:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0gd-0004WN-NQ; Mon, 24 Oct 2005 07:40:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0gb-0004WF-8Z for tsvwg@megatron.ietf.org; Mon, 24 Oct 2005 07:40:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03592 for ; Mon, 24 Oct 2005 07:40:03 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU0tK-00088M-Mz for tsvwg@ietf.org; Mon, 24 Oct 2005 07:53:28 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j9OBeAjt008312 for ; Mon, 24 Oct 2005 07:40:10 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <435CC81A.8050406@stewart.chicago.il.us> Date: Mon, 24 Oct 2005 07:40:10 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: TSWG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] I-G X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org All: I have just submitted v16 ... its as we discussed.. but I did add 3 sentences in Appendix C on the diff with rfc1122 (we may need some word-smithing here :-D) You can find a diff to v14 at: http://www.sctp.org/draft-ietf-tsvwg-sctpimpguide-16-from-4.diff.html I did the diff to 14 since that was the doc that was "last called".. in our extended last call :-D R -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 24 15:46:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8H1-0001tg-8m; Mon, 24 Oct 2005 15:46:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8Gv-0001t8-2N for tsvwg@megatron.ietf.org; Mon, 24 Oct 2005 15:46:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28398 for ; Mon, 24 Oct 2005 15:46:02 -0400 (EDT) Received: from hammerhead.shentel.net ([204.111.11.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU8Ti-0007L8-OX for tsvwg@ietf.org; Mon, 24 Oct 2005 15:59:32 -0400 Received: from Steve ([204.111.103.222]) by hammerhead.shentel.net (8.13.3/8.13.3) with SMTP id j9OJjpJD012965; Mon, 24 Oct 2005 15:45:53 -0400 From: "Steve Silverman" To: "Jon Peterson" , "James M. Polk" , "TSVWG" , "Allison Mankin" Subject: [TSVWG] Multi-Level Expedited Forwarding Date: Mon, 24 Oct 2005 15:46:25 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: Howard Nhan , Mike Pierce X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Multi-Level Expedited Forwarding I (along with Mike Pierce and other people) have been proposing Multi-Level Expedited Forwarding as a way to implement a form of MLPP (Multi-level Precedence & Preemption) for some years. All we want to get approval as an Experimental RFC. This would create a stable document that would allow the proper experimentation to see if this is necessary and what else is needed to support the MLPP feature. I want to point out: The DOD (and many other organizations) have limited bandwidth and consequently do have a congestion problem. The DOD really does need a multi-level priority voice system. They have spent a large amount of money to implement this over 40 years. MLEF works at a different level than a CAC (Call Admission Control) and does not conflict in any way. They work at different layers. This allows rapid response but does not allow MLEF to do call control. They compliment each other. If there is no congestion, MLEF does not affect the data stream. MLEF is very simple to implement and has several implementations been done and worked. MLEF is simple enough that there is no significant processing load at execution time. As has been pointed out, packet losses are in general confined to the routine traffic. In a congested network, something has to be discarded and routine traffic is by definition where we want necessary losses to occur. "MLPP-that Works" will NOT meet DOD requirements. The DOD network packet encryptors (High Assurance Packet Encryptors) will hide the RSVP messages from the network. We have no problem with approval of this document but think it should be made more explicit that this ID may be useful for other networks but won't meet DOD needs. This is mentioned in the ID but a great deal of the current draft is DOD related and one might conclude that the draft is pertinent to the DOD. MLEF is part of a solution to the MLPP problem that will work despite network packet encryption. Given the demand for voice in networks that may occasionally be congested, I still think this draft (currently draft-silverman-tsvwg-mlefphb-03.txt) should be considered by the WG. I would ask others that think this should be worked by this group (or another) to support this. Steve Silverman _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 25 16:38:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVYk-00010n-KU; Tue, 25 Oct 2005 16:38:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVYi-00010I-B5 for tsvwg@megatron.ietf.org; Tue, 25 Oct 2005 16:38:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03324 for ; Tue, 25 Oct 2005 16:37:57 -0400 (EDT) Received: from athena.hosts.co.uk ([212.84.175.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUVli-00061y-GK for tsvwg@ietf.org; Tue, 25 Oct 2005 16:51:40 -0400 Received: from [69.138.71.61] (helo=[192.168.1.100]) by athena.hosts.co.uk with esmtpa (Exim 4.52) id 1EUVY0-0005lJ-PH; Tue, 25 Oct 2005 21:37:39 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76425A51-BFC5-4FC4-9FF8-0D54D9458E96@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [TSVWG] Multi-Level Expedited Forwarding Date: Tue, 25 Oct 2005 16:37:20 -0400 To: Steve Silverman X-Mailer: Apple Mail (2.734) X-Spam-Score: 2.0 (++) X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Howard Nhan , TSVWG , Jon Peterson , Allison Mankin , "James M. Polk" , Mike Pierce X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org > I still think this draft (currently > draft-silverman-tsvwg-mlefphb-03.txt) > should be considered by the WG. I would ask others that think this > should be worked by this group (or another) to support this. pardon my confusion, but I was under the impression from the last Minneapolis-IETF (#62) that both the Polk & Baker MLPP draft as well as the Silverman/MLEF draft were to be taken on as official TSVWG documents. I thought that Scott Bradner had recommended this course of action (and the minutes *seem* to bear this out) and that the chairs agreed. but please correct me if I'm mistaken. -ken _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 25 16:51:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVm0-0003XP-BD; Tue, 25 Oct 2005 16:51:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVlx-0003NZ-Hs for tsvwg@megatron.ietf.org; Tue, 25 Oct 2005 16:51:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10403 for ; Tue, 25 Oct 2005 16:51:38 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUVyx-0000NQ-7z for tsvwg@ietf.org; Tue, 25 Oct 2005 17:05:21 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 25 Oct 2005 13:51:41 -0700 X-IronPort-AV: i="3.97,250,1125903600"; d="scan'208"; a="356609724:sNHT27666408" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9PKpc94025371; Tue, 25 Oct 2005 13:51:39 -0700 (PDT) Received: from [10.30.173.242] (ams-clip-vpn-dhcp4302.cisco.com [10.61.80.205]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9PL1YZB006514; Tue, 25 Oct 2005 14:01:38 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <893C2713-5D1C-433E-AB23-07CFCCDC2F36@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [TSVWG] Multi-Level Expedited Forwarding Date: Tue, 25 Oct 2005 05:12:33 +0200 To: "Steve Silverman" X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=664; t=1130274100; x=1130706300; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20[TSVWG]=20=20=20=20Multi-Level=20Expedited=20Forwarding| From:Fred=20Baker=20| Date:Tue,=2025=20Oct=202005=2005=3A12=3A33=20+0200| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=cfYTbHS3QptlHKCjcU5uJsA3GSagv4NAgBfLzX1sremeQlITHqN67zyZlfyRVpssH/o3SKQB 4jS3JWxL9MdlIrotjIw9B4TJvWz+YHLVIt9aM3sPRsgGCDU7mt3nGFg9gQK9DjcOPBBlwhFxqjK IJ2dYQhBMrd5Q7F93dy952kA= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.4 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Howard Nhan , TSVWG , Jon Peterson , Allison Mankin , "James M. Polk" , Mike Pierce X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org On Oct 24, 2005, at 9:46 PM, Steve Silverman wrote: > "MLPP-that Works" will NOT meet DOD requirements. > The DOD network packet encryptors (High Assurance Packet > Encryptors) will hide the RSVP messages from the network. As you know, DoD does not intend to deploy MLEF either. If MLEF is published as an RFC, the the document that points out the issues it raises should also be published. That note has been allowed to expire at Mike Pierce's request, as it should be generalized to cover the issues with heuristic-based algorithms in general, including the proposed heuristics related to ECN, and I have not done that. The water has, however, flown quite a way beyond that particular bridge, and now DoD was present officially at the last IETF meeting and will be conducting an ad hoc BOF at this one. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 25 17:51:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWht-0005u8-PY; Tue, 25 Oct 2005 17:51:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWhr-0005tJ-6N for tsvwg@megatron.ietf.org; Tue, 25 Oct 2005 17:51:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17106 for ; Tue, 25 Oct 2005 17:51:27 -0400 (EDT) Received: from mailgw3a.lmco.com ([192.35.35.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUWus-0003OR-5X for tsvwg@ietf.org; Tue, 25 Oct 2005 18:05:11 -0400 Received: from emss09g01.ems.lmco.com (relay6.ems.lmco.com [166.17.13.59]) by mailgw3a.lmco.com (8.12.10/8.12.10) with ESMTP id j9PLc5XL021391; Tue, 25 Oct 2005 17:49:50 -0400 (EDT) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0IOX00001Q5OFK@lmco.com>; Tue, 25 Oct 2005 17:25:00 -0400 (EDT) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0IOX00L5JQ5OUT@lmco.com>; Tue, 25 Oct 2005 17:25:00 -0400 (EDT) Received: from EMSS04M14.us.lmco.com ([162.16.20.50]) by EMSS09I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Oct 2005 17:25:00 -0400 Date: Tue, 25 Oct 2005 17:24:59 -0400 From: "Bose, Pratik" Subject: RE: [TSVWG] Multi-Level Expedited Forwarding To: Fred Baker , Steve Silverman Message-id: <37B6F612D86CA143B5F965E9EE8BD7AA0C0E04A6@emss04m14.us.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [TSVWG] Multi-Level Expedited Forwarding Thread-Index: AcXZpivD3OB9x34DQbeBCy7QiFkB9wAAW6nw content-class: urn:content-classes:message X-OriginalArrivalTime: 25 Oct 2005 21:25:00.0139 (UTC) FILETIME=[8E15D3B0:01C5D9AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7BIT Cc: Howard Nhan , TSVWG , Jon Peterson , Allison Mankin , "James M. Polk" , Mike Pierce X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org On Oct 24, 2005, at 9:46 PM, Steve Silverman wrote: > "MLPP-that Works" will NOT meet DOD requirements. This is at best an assumption, Steve, which does not have general acceptance, even amongst people like you and me, who supply to the DoD. If the DoD is now present at the IETF as indicated by Fred, why don't we leave what DoD requires, for the DoD to say ? > The DOD network packet encryptors (High Assurance Packet > Encryptors) will hide the RSVP messages from the network. Network encryptors hiding RSVP messages does not mean the mechanism described in MLPP-That-Works is no longer feasible. TSVWG itself has a couple of documents which describe the behavior of RSVP in such environments. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 25 18:50:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUXcZ-00058l-Hu; Tue, 25 Oct 2005 18:50:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUXcJ-0004sz-Ij; Tue, 25 Oct 2005 18:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20454; Tue, 25 Oct 2005 18:49:47 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUXpL-00058K-Ak; Tue, 25 Oct 2005 19:03:32 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUXcH-0004Pd-Oc; Tue, 25 Oct 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 25 Oct 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-tcp-mib-extension-08.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : TCP Extended Statistics MIB Author(s) : M. Mathis, et al. Filename : draft-ietf-tsvwg-tcp-mib-extension-08.txt Pages : 70 Date : 2005-10-25 This draft describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-tcp-mib-extension-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-25155009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-tcp-mib-extension-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-25155009.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --NextPart-- From tsvwg-bounces@ietf.org Thu Oct 27 10:51:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV96I-0003wO-FN; Thu, 27 Oct 2005 10:51:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV952-0003VD-Q4; Thu, 27 Oct 2005 10:50:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04007; Thu, 27 Oct 2005 10:49:56 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9IH-0004Wl-9q; Thu, 27 Oct 2005 11:03:57 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EV94s-0000IW-Fp; Thu, 27 Oct 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 10:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-16.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Specification Errata and Issues Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-sctpimpguide-16.txt Pages : 109 Date : 2005-10-27 This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using SCTP along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time based way. The issues are listed in the order they were brought up. Because some text is changed several times the last delta in the text is the one which should be applied. In addition to the delta a description of the problem and the details of the solution are also provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-sctpimpguide-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-27095324.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpimpguide-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27095324.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --NextPart-- From tsvwg-bounces@ietf.org Thu Oct 27 18:34:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVGKR-0003h9-TW; Thu, 27 Oct 2005 18:34:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVGKO-0003eN-6G for tsvwg@megatron.ietf.org; Thu, 27 Oct 2005 18:34:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21678 for ; Thu, 27 Oct 2005 18:34:15 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVGXp-0003Cq-7M for tsvwg@ietf.org; Thu, 27 Oct 2005 18:48:26 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2005 15:34:22 -0700 X-IronPort-AV: i="3.97,259,1125903600"; d="scan'208"; a="224675641:sNHT25859884" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9RMYG8m016797; Thu, 27 Oct 2005 15:34:18 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 15:34:17 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 15:34:16 -0700 Message-Id: <4.3.2.7.2.20051027172150.03455ee8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Oct 2005 17:33:52 -0500 To: ken carlberg , Steve Silverman From: "James M. Polk" Subject: Re: [TSVWG] Multi-Level Expedited Forwarding In-Reply-To: <76425A51-BFC5-4FC4-9FF8-0D54D9458E96@g11.org.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Oct 2005 22:34:17.0093 (UTC) FILETIME=[90A62B50:01C5DB46] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Mike Pierce , Howard Nhan , TSVWG , Jon Peterson , Allison Mankin X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org As an author of the counter to this ID, I remember the discussion involving Scott wrt modifying MLEF-Concerns for a wider audience being acceptable to the WG. I can't say I remember the MLEF spec document clearing WG consensus to become a WG item though. This can be discussed in Vancouver. At 04:37 PM 10/25/2005 -0400, ken carlberg wrote: >>I still think this draft (currently >>draft-silverman-tsvwg-mlefphb-03.txt) >>should be considered by the WG. I would ask others that think this >>should be worked by this group (or another) to support this. > >pardon my confusion, but I was under the impression from the last >Minneapolis-IETF (#62) that both the Polk & Baker MLPP draft as well >as the Silverman/MLEF draft were to be taken on as official TSVWG >documents. I thought that Scott Bradner had recommended this course >of action (and the minutes *seem* to bear this out) and that the >chairs agreed. > >but please correct me if I'm mistaken. > >-ken cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg