From bxxpwg-admin@lists.invisibleworlds.com Mon Feb 19 15:45:11 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14353 for ; Mon, 19 Feb 2001 15:45:10 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id MAA01744; Mon, 19 Feb 2001 12:43:38 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id MAA01718 for ; Mon, 19 Feb 2001 12:43:36 -0800 (PST) Received: from [64.198.230.35] (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2) for ; Mon, 19 Feb 2001 14:42:09 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Mon, 19 Feb 2001 14:42:06 -0600 To: bxxpwg@lists.invisibleworlds.com From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [BXXPwg] Intros and meeting query Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Greetings all, As BEEP is winding down, and since Keith has other commitments to attend to, I'm sitting in for him as chair. I'll be playing a little catchup to see what's going on and what needs attention, so feel free to float me private e-mail if you think there are issues that I should be looking at other than what's been discussed on the list. In the meanwhile, Minneapolis is coming up soon. Is there a need for a WG meeting? Let me know in the next few days as I must request space before Monday. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Feb 23 11:03:25 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06494 for ; Fri, 23 Feb 2001 11:03:23 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id IAA03271; Fri, 23 Feb 2001 08:01:28 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id IAA03256 for ; Fri, 23 Feb 2001 08:01:27 -0800 (PST) Received: from [208.54.4.87] (10.0.1.3) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2) for ; Fri, 23 Feb 2001 09:59:37 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Fri, 23 Feb 2001 09:59:59 -0600 To: bxxpwg@lists.invisibleworlds.com From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [BXXPwg] No BEEP meeting in Minneapolis Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Sounds to me like we won't be meeting in Minneapolis. If there are any outstanding issues, get them posted to the list. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Feb 23 14:22:40 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16483 for ; Fri, 23 Feb 2001 14:22:39 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA00677; Fri, 23 Feb 2001 11:21:05 -0800 (PST) Received: from ambassador.warpspeedcom.com (ambassador.warpspeed.net [199.108.64.2]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with SMTP id LAA00656 for ; Fri, 23 Feb 2001 11:21:04 -0800 (PST) Received: from vanwall01.warpspeed.net(vanwall[199.108.64.198]) (2714 bytes) by ambassador.warpspeedcom.com via sendmail with P:smtp/R:internet/T:rsmtp (sender: ) id for ; Fri, 23 Feb 2001 11:06:45 -0800 (PST) (Smail-3.2.0.106 1999-Mar-31 #1 built 1999-Jun-20) Received: from warpmail.warpspeed.net by vanwall01.warpspeed.net via smtpd (for ambassador.warpspeed.net [199.108.64.2]) with SMTP; 23 Feb 2001 19:20:55 UT Received: from kallisti by warpmail.warpspeed.net (8.8.8+Sun/SMI-SVR4) id LAA05480; Fri, 23 Feb 2001 11:20:45 -0800 (PST) Message-Id: <200102231920.LAA05480@warpmail.warpspeed.net> Date: Fri, 23 Feb 2001 11:20:44 -0800 Content-Type: text/plain; format=flowed; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v381) From: j h woodyatt To: bxxpwg@lists.invisibleworlds.com X-Mailer: Apple Mail (2.381) Content-Transfer-Encoding: 7bit Subject: [BXXPwg] you asked for outstanding issues? Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit comrades-- What do we want to do about implementation issues? I have found several. I think they're all resolvable within the specifications as they exist now, but I suspect we should be documenting our implementation experiences somewhere. Did I miss the announcement that we were doing that in some other mail list? I think it would be worth documenting the steps necessary to keep a BEEP listener from behaving poorly in the face of actively hostile initiators. For example, there's a fairly amusing denial-of-service attack I've devised. Consider the following pathological variant on the greeting message: Content-type: application/beep+xml ; Fri, 23 Feb 2001 18:32:58 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA02619; Fri, 23 Feb 2001 15:31:41 -0800 (PST) Received: from ambassador.warpspeedcom.com (ambassador.warpspeed.net [199.108.64.2]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with SMTP id PAA02604 for ; Fri, 23 Feb 2001 15:31:40 -0800 (PST) Received: from vanwall01.warpspeed.net(vanwall[199.108.64.198]) (3221 bytes) by ambassador.warpspeedcom.com via sendmail with P:smtp/R:internet/T:rsmtp (sender: ) id for ; Fri, 23 Feb 2001 15:17:20 -0800 (PST) (Smail-3.2.0.106 1999-Mar-31 #1 built 1999-Jun-20) Received: from warpmail.warpspeed.net by vanwall01.warpspeed.net via smtpd (for ambassador.warpspeed.net [199.108.64.2]) with SMTP; 23 Feb 2001 23:31:36 UT Received: from kallisti by warpmail.warpspeed.net (8.8.8+Sun/SMI-SVR4) id PAA07883; Fri, 23 Feb 2001 15:31:26 -0800 (PST) Message-Id: <200102232331.PAA07883@warpmail.warpspeed.net> Date: Fri, 23 Feb 2001 15:31:25 -0800 From: j h woodyatt Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: [BXXPwg] you asked for outstanding issues? Cc: bxxpwg@lists.invisibleworlds.com To: Darren New X-Mailer: Apple Mail (2.381) In-Reply-To: <3A96D606.63DA1EE0@san.rr.com> Mime-Version: 1.0 (Apple Message framework v381) Content-Transfer-Encoding: 7bit Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit On Friday, February 23, 2001, at 01:28 PM, Darren New wrote: > j h woodyatt wrote: >> I think it would be worth documenting the steps necessary to keep a >> BEEP >> listener from behaving poorly in the face of actively hostile >> initiators. For example, there's a fairly amusing denial-of-service >> attack I've devised. > > But that only denies the service to the session that's doing that, > right? I > mean, why is this more a denial of service than simply opening the > connection and not sending anything? > [...] > Aren't they all basically run-out-of-memory or run-off-the-buffer > concerns, > tho? Yeah, but this one has the potential to be very destructive if the BEEP listener is implemented improperly. For the example I gave, if the listener gives buffer space to channel zero after feeding each frame of a message into its XML parser (sending SEQ frames as suggested by the TCP mapping document), then what happens? If your XML parser is Expat, and you aren't careful, the buffer containing the 'uri' attribute accumulates the received characters until there is no memory left, or until the sender eventually declines your SEQ invitations to send more data. If the BEEP listener manages multiple sessions inside the same process space, then one anonymous untraced initiator can crash all the sessions managed by the listener-- maybe it can even crash the entire host by making it thrash to death. Distributed attacks aren't necessary. Another delightful attack is to keep sending CDATA content in a , , or message, without ever sending the end tag for the message. Which makes me, as an implementer, ask the following question: how much buffer space should I give to channel zero for receiving elements? (Take into consideration that elements may or may not have CDATA content, depending on the profile. Note: there is no size limit imposed by the BEEP core on those CDATA parts.) There are reasonable precautions implementers should take to prevent such simple service denial attacks from being so wildly successful. Are we collecting it? Where? -- j h woodyatt "And the difference between the CIA and a religious cult is... what, again?" --drieux _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Feb 23 18:40:01 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26894 for ; Fri, 23 Feb 2001 18:40:00 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA02687; Fri, 23 Feb 2001 15:39:00 -0800 (PST) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with SMTP id PAA02668 for ; Fri, 23 Feb 2001 15:38:58 -0800 (PST) Received: (qmail 55845 invoked by uid 3039); 23 Feb 2001 23:38:53 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 Feb 2001 23:38:53 -0000 Date: Fri, 23 Feb 2001 15:38:53 -0800 (PST) From: Gabe Wachob X-Sender: To: j h woodyatt cc: Darren New , Subject: Re: [BXXPwg] you asked for outstanding issues? In-Reply-To: <200102232331.PAA07883@warpmail.warpspeed.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net As an implementor, collecting these sort of issues would be helpful. I'm not sure that these sort of issues have been discussed on this list at all before. I know that I have not had many of these issues in mind when working on the Python implementation. I have focused on spec compliance. -Gabe On Fri, 23 Feb 2001, j h woodyatt wrote: > On Friday, February 23, 2001, at 01:28 PM, Darren New wrote: > > j h woodyatt wrote: > >> I think it would be worth documenting the steps necessary to keep a > >> BEEP > >> listener from behaving poorly in the face of actively hostile > >> initiators. For example, there's a fairly amusing denial-of-service > >> attack I've devised. > > > > But that only denies the service to the session that's doing that, > > right? I > > mean, why is this more a denial of service than simply opening the > > connection and not sending anything? > > [...] > > Aren't they all basically run-out-of-memory or run-off-the-buffer > > concerns, > > tho? > > Yeah, but this one has the potential to be very destructive if the BEEP > listener is implemented improperly. > > For the example I gave, if the listener gives buffer space to channel > zero after feeding each frame of a message into its XML parser (sending > SEQ frames as suggested by the TCP mapping document), then what happens? > > If your XML parser is Expat, and you aren't careful, the buffer > containing the 'uri' attribute accumulates the received characters until > there is no memory left, or until the sender eventually declines your > SEQ invitations to send more data. > > If the BEEP listener manages multiple sessions inside the same process > space, then one anonymous untraced initiator can crash all the sessions > managed by the listener-- maybe it can even crash the entire host by > making it thrash to death. Distributed attacks aren't necessary. > > Another delightful attack is to keep sending CDATA content in a , > , or message, without ever sending the end tag > for the message. Which makes me, as an implementer, ask the following > question: how much buffer space should I give to channel zero for > receiving elements? (Take into consideration that > elements may or may not have CDATA content, depending on the profile. > Note: there is no size limit imposed by the BEEP core on those CDATA > parts.) > > There are reasonable precautions implementers should take to prevent > such simple service denial attacks from being so wildly successful. Are > we collecting it? Where? > > > -- > j h woodyatt > "And the difference between the CIA and > a religious cult is... what, again?" --drieux > > _______________________________________________ > BXXPwg mailing list > BXXPwg@lists.invisible.net > http://lists.invisible.net/mailman/listinfo/bxxpwg > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg