Re: [beepwg] A couple of features to limit BEEP no reply attack
Francis Brosnan Blazquez <francis@aspl.es> Wed, 18 March 2009 13:10 UTC
Return-Path: <beepwg-bounces@beepcore.org>
X-Original-To: ietfarch-beep-archive@core3.amsl.com
Delivered-To: ietfarch-beep-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DFB3A687C for <ietfarch-beep-archive@core3.amsl.com>; Wed, 18 Mar 2009 06:10:11 -0700 (PDT)
X-Quarantine-ID: <JMVjjAHZMwHQ>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level:
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=1.177, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMVjjAHZMwHQ for <ietfarch-beep-archive@core3.amsl.com>; Wed, 18 Mar 2009 06:10:10 -0700 (PDT)
Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id A1B1C28C16A for <beep-archive@lists.ietf.org>; Wed, 18 Mar 2009 06:10:09 -0700 (PDT)
Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 07DF27B396E; Wed, 18 Mar 2009 14:10:47 +0100 (CET)
X-Original-To: beepwg@beepcore.org
Delivered-To: beepwg-lista@hl27.dinaserver.com
Received: from dolphin.aspl.es (unknown [212.170.183.66]) by hl27.dinaserver.com (Postfix) with ESMTP id 3C6E97B2D10 for <beepwg@beepcore.org>; Wed, 18 Mar 2009 14:10:35 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by dolphin.aspl.es (Postfix) with ESMTP id 3BB43740F8; Wed, 18 Mar 2009 14:05:26 +0100 (CET)
X-Virus-Scanned: amavisd-new at dolphin.aspl.es
Received: from dolphin.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5Nd6yT+JnX3; Wed, 18 Mar 2009 14:05:21 +0100 (CET)
Received: from [192.168.0.132] (barracuda [10.0.0.4]) by dolphin.aspl.es (Postfix) with ESMTP id F240774054; Wed, 18 Mar 2009 14:05:20 +0100 (CET)
Subject: Re: [beepwg] A couple of features to limit BEEP no reply attack
From: Francis Brosnan Blazquez <francis@aspl.es>
To: David Kramer <dkramer@apple.com>
In-Reply-To: <9471C896-E007-4745-8A49-885D51B6B130@apple.com>
References: <1236942381.17324.180.camel@vulcan.aspl.local> <9471C896-E007-4745-8A49-885D51B6B130@apple.com>
Content-Type: text/plain
Organization: Advanced Software Production Line, S.L.
Date: Wed, 18 Mar 2009 14:10:29 +0100
Message-Id: <1237381829.5260.269.camel@vulcan.aspl.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Content-Transfer-Encoding: 7bit
X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado.
X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.499, requerido 6, BAYES_00 -2.60, RDNS_NONE 0.10),
cc: Vortex <vortex@lists.aspl.es>
cc: BEEPwg <beepwg@beepcore.org>
X-BeenThere: beepwg@beepcore.org
X-Mailman-Version: 2.1
Precedence: list
List-Id: <beepwg.beepcore.org>
List-Help: <mailto:beepwg-request@beepcore.org?subject=help>
List-Post: <mailto:beepwg@beepcore.org>
List-Subscribe: <http://beepcore.org/mailman/listinfo/beepwg>, <mailto:beepwg-request@beepcore.org?subject=subscribe>
List-Unsubscribe: <http://beepcore.org/mailman/listinfo/beepwg>, <mailto:beepwg-request@beepcore.org?subject=unsubscribe>
Sender: beepwg-bounces@beepcore.org
Errors-To: beepwg-bounces@beepcore.org
X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus
X-MailScanner-ID: 07DF27B396E.25733
X-DinaScanner-From: beepwg-bounces@beepcore.org
Hi David, > First, regarding reply-limit: > > * The reply-limit feature could be implemented by the library > implementing the BEEP protocol. The library could automatically > terminate the session whenever it determined that the remote peer was > taking too long to reply to requests. Clients using the library could > override this timeout value on a per-session and per-channel basis. > Can you provide an example showing why it is better to make this a > feature of the BEEP protocol instead of just implementing this in the > library? Ok. In general, having a BEEP peer with pending replies is a problem yet not solved. This drives to a situation where users start to doing the only thing that can solve this, assuming session close requirements, that is, to shutdown the session. It is important to note this is a protocol violation. Knowing this, you can think you can implement a per-session or per-channel policy (out of the BEEP context) to take a measure, but, at end, having a BEEP session with only one channel (including 0) with pending replies yields to the same solution, again, you have to shutdown the session (mainly because you'll never fulfill BEEP close requirements in such context). With the time you find people asking "why my app gets blocked on session or channel close?". When you answer to this question people find they have to shutdown the connection to ensure, in every case, they will never be blocked. So, as a general conclusion I find that: 1) All solutions comes to shutdown the session in the case of pending replies. 2) All of them are always activated via timeout. 3) Current solution is a protocol violation. Assuming these factors I find convenient providing a standard API, especially to site administrators, to model the solution that is currently accepted (or at least I think so) rather making all people to go into a creative process (which again, it is a protocol violation). >From the perspective of a general purpose BEEP application server, makes sense providing an API that will provide site administrators with the basis to implement and configure session timeout as currently accepted (based on channel numbers, profiles running on them and their network setup/bandwidth) but within the standard. (Note: I refer to API as the BEEP server side configuration that will be available if reply-limit or a similar feature appears). However, and I think the most important, you shouldn't implement this in the library without being supported by the protocol. I mean, having a BEEP peer that closes connections its a protocol violation. BEEP clearly states you can't do this. However, the feature will allow, under required situation, and supported by the protocol, to close after such timeout, which was previously advised. > * When using reply-limit, if peer A takes longer than the limit to > reply, is it considered a protocol violation if peer B doesn't > terminate the session? In other words, who's responsibility is it to > enforce the reply-limit? Both peers? Or just the receiving peer? I didn't think about this ;-) Assuming "reply-limit" is meanly designed to allow BEEP peer to advice its intention to consider a protocol violation to not reply within a period, I don't find a protocol violation to not proceeding after timeout expiration. I'm not sure what would be the best option for this. Maybe you can provide some insights on how to proceed here. > Regarding "no-reply": > > * Because the "no-reply" feature still allows replies, a downside of > using "no-reply" instead of NFN messages is that each peer still has > to keep track of all of the un-replied-to messages it has sent, in > order to verify that each RPY that does arrive has a valid msgno. The > peer's memory usage will increase for each message it sends that the > remote peer does not reply to. Do you agree that this feature would > be unusable in low-memory environments, unless the peer stopped > validating the msgno of incoming RPY messages? Yes, I agree. "no-reply" only disables channel close requirements. Maybe it is time for a true one-way notification. My intention was never to have one-way notification but a way to protect BEEP listeners against no reply attack. > * The issue you mention about the NFN scheme not supporting > correlation between requests and replies was first raised because I > suggested that the NFN scheme could be used to implement support for > out-of-order replies. As was pointed out to me, and I agree, the > application would have to do extra work to correlate these out-of- > order replies, which could instead be handled by the msgno value in > the frame header if the protocol were changed to allow out of order > RPYs. But in the cases where you do not want a reply, this issue does > not apply. Yes, I agree. > * The "no-reply" feature seems mis-named. You are not creating a > channel in which there are no replies, you are creating a channel in > which replies are optional, and the choice is made by the receiver, > not the sender. This does not seem like a useful feature to me. I > would understand a feature that allowed for a channel on which replies > were not allowed at all (eg, it is against the rules to send a RPY > when you receive a MSG on the channel) and I would understand a > feature that allowed for channel on which the sender specified whether > or not a RPY was needed (eg, the sender could send a NFN if it didn't > want a RPY, and it could send a MSG if it did want a RPY)... but I > don't understand the "no-reply" feature, because it allows the > receiver to decide whether or not to respond. Ok. > Can you provide an > example protocol where it is useful to allow the receiving peer the > option to decide whether or not it replies? As an example we can have all request/response protocols created by people. From my experience with Vortex I find people have little or no interest in having all content flushed in both directions, etc (close requirements). However, they find really useful having a quick way to close the connection, no matter if there are pending replies. In fact, I've announced this draft in the Vortex list and it is having a well reception (especially no-reply feature). >From the perspective of a client requesting for some resource at a listener, it is too hard to wait for all pending replies to outstanding messages. Think about those cases where you want to stop/exit from your client application (no matter pending messages). > Also, I suggest renaming > the feature to "optional-reply". Ok. I see it more appropriate. > Regarding the over-all goal of limiting BEEP no reply attack: > > * Anytime a remote peer does not behave the way you want, you have the > right to terminate the session. I don't think so. BEEP clearly states you can't do this. This is the problem I see. Reducing the issue, you have under the same classification BEEP peers that are just taking long to generate a reply, with BEEP peer not behaving properly. I think you can't apply the same solution for both. > Why is this not sufficient for > protecting against the no reply attack? Can't all of this just be > implemented by the library? For example, if the client of the library > asks to close a channel, and the remote peer refuses, the library > could automatically terminate the session -- or it could terminate the > session on the third failed attempt -- or whatever policy you want. > And if the client of the library sends a message but receives no reply > after some timeout, the library could automatically terminate the > session. Does any of this have to be part of the protocol? I think this is not a technical reason. I find that the solution applied at the end it's the same, that is, shutting down the session. However not providing a solution within the BEEP protocol will leave people with an insane pattern, which is a protocol violation, that is becoming an accepted practice making protocols that requires "patience", like relay servers or central software with agents, to be not practicable (unless the same toolkit is used). > What is > the advantage of broadcasting your reply-limit to the other peer? If > I tell you my reply-limit is 10, and you take 11 seconds to reply on > channel 0, I'll terminate the session. But I could do the same even > if I didn't tell you what my reply-limit is, right? Yes. > What is the > difference? Mainly because you can go closing BEEP session because you find it is more appropriate. This is a protocol violation. Again, one of the BEEP power relay in the fact that peers won't do this. "reply-limit" only seek to enforce BEEP peers, especially on channel 0, to reply to request performed. These replies shouldn't take long assuming they are start and close channel requests. Broadcasting reply-limit is just a notification that you will be implementing such timeout. Without it, remote BEEP peer is allowed to take all the time he wants to process your request, with no limit, and you can't close its session. Doing so, without an advice of any form, is not what BEEP standard says. > * In the case where a peer is is performing the permanent negative > close attack on only one channel, I could see the use for a "channel > terminate" message that the peer could send over channel 0 to indicate > that it would no longer consider valid any messages sent with that > channel number. Do you think this would solve the problem > effectively? If the remote peer is performing the permanent negative > close attach on all channels (or just on channel 0) then terminating > the session is already the appropriate response, right? I think permanent negative attack, especially with public BEEP services used by untrusted peer, have only one solution: to shutdown the session after some tries. At the end, even having such new invalidation message, you will have to also modify what BEEP says about closing a channel, stating that channels "invalidated" are ignored during the close process, which is elaborated form of saying "just close the session". > You goal of limiting BEEP no reply attacks is good, but I don't yet > see any compelling reasons to make the features you have described > part of the protocol. If you can describe some profiles where these > features would be useful it might be easier for me to understand the > purpose of the features and comment on them more effectively. I disagree. I think there are enough reason, at least for "optional-reply". Rather placing some examples, let me summarize with all points: >From my experience with Vortex and hearing people that use it, I perceive "optional-reply" as really useful. The explanation is simply: most of people only want to do request/response protocols/applications and mostly all of them finds annoying current close requirements. In fact, I think most of these people are shutting down connection before closing to avoid any lock issue. It is worth to mention, again, this is an insane pattern, hides bugs (you don't have to face with missing replies, etc) and disables an important part of BEEP, the session close, which is beneficial for the user if properly used. For the case of "reply-limit", I think it is an good attempt to conciliate those profiles that could take advantage of current close requirements as defined by RFC3080 and those protocols that only uses the exchange part of the BEEP protocol. At the end David, I can place some examples but we will both end up saying either "you can close the session via library" or "you can close the session via timeout already notified via reply-limit". "reply-limit" provides a chance to the developer to decide if its protocol cares about replies or not, avoiding the general pattern "in case of doubt, shutdown the session". Not accepting "reply-limit" will imply that the current practice will be applied to all protocols and, as a side effect, will invalidate a complete section from the RFC which describes session close requirements. In the other hand, taking the problem with a different point of view, maybe "reply-limit" is not necessary because nobody cares about close requirements, that is, all people is shutting down the session with no problem at all. Can someone say something about this? Thanks for your comments David. Cheers! > Thanks, > David -- Francis Brosnan Blazquez <francis@aspl.es> Advanced Software Production Line, S.L.
- [beepwg] A couple of features to limit BEEP no re… Francis Brosnan Blazquez
- [beepwg] Re: [Vortex] A couple of features to lim… Francis Brosnan Blazquez
- Re: [beepwg] A couple of features to limit BEEP n… David Kramer
- [beepwg] Re: A couple of features to limit BEEP n… Martin Thomson
- [beepwg] Re: [Vortex] A couple of features to lim… Francis Brosnan Blazquez
- Re: [beepwg] A couple of features to limit BEEP n… Francis Brosnan Blazquez
- Re: [beepwg] Re: A couple of features to limit BE… Francis Brosnan Blazquez
- RE: [beepwg] Re: A couple of features to limit BE… Thomson, Martin
- RE: [beepwg] Re: A couple of features to limit BE… Francis Brosnan Blazquez
- [beepwg] Re: [Vortex] A couple of features to lim… Benoit Amiaux
- Re: [beepwg] Re: A couple of features to limit BE… Francis Brosnan Blazquez
- Re: [beepwg] Re: [Vortex] A couple of features to… Francis Brosnan Blazquez