Hi, On 7/14/10 1:51 PM, Geoff Huston wrote: >> >> >> @3.6 Request-Not-Performed Response >> >> >> >> This document is about the communication protocol not the actual >> implementation. However, for server implementations it may be useful to >> be able to do the following: >> >> 1) process requests asynchronously >> 2) throttle client requests >> >> >> >> @1: asynchronous processing >> >> A use case for this is when additional manual security checks such as >> FIPS-140-2 level 3 authentication are required to sign a certificate. >> >> >> We are running into this one now that we are thinking of using the >> provisioning protocol between our production CA and our local test TA CA. >> >> >> >> In this case it would be good if the server could respond with a >> dedicated code informing the client that the request has been received >> and okay’d but processing will take time. >> >> The existing code 1101 seems ambiguous. I would suggest an additional >> code: 1104 - request scheduled for processing. >> >> Also it would be good >> to include advisory text for the client. In this case I think the client >> should send the same request some time later, eg 24 hours. If the >> request has been performed by then it will get back the proper response. >> Otherwise the same error as above. >> >> > > This synchronous / asynch issue was last discussed about two years ago. I > have some (indistinct) memory about issues over synchronization over issuance > and revocation requests, but I'm not sure I can accurately reproduce the > conversation some years on. >
I also asked this question in another email sent 26 May this year. Without getting any response. I have been on the list for a while, but have nothing on this in my archives and I can not find anything in the online list archives either. So if someone remembers I would appreciate some pointers. As I said I think we can just re-use the existing 1101 code for this. But.. it seems to me that this may be ambiguous. Also if we have an explicit 'async' response, this will force clients to be able to handle such a case. > >> >> @2: throttle requests >> >> It may prove necessary to throttle client access. >> >> For example if a >> client sets up an automated system (misconfigures), to see if new >> classes are available, and/or requests new certificates every five >> minutes.. this may cause a big load on a system. >> >> > > > Why wouldn't the server go slower and simply respond with > > 1101 already processing request > > ? > well, I feel that would only be valid if it's actually processing the requests. It may be that they are all different. In which case the answer would be wrong. And it still takes processing power, see below.. I don't want to go slower, because then I am loosing connectors and the pool is limited. > > >> >> I think we lack practical experience to know for sure whether this is >> going to be problematic in the real world (and what an acceptable access >> rate should be), but on the protocol level I think it would be useful if >> the server _could_ send clients an error response to this effect. E.g. >> 1105 - too many requests >> . >> > > > I'm not sure its an altogether good idea personally. > > i.e. "DOS attack is working, keep it up" ? > True. But as it is now the server is required to come up with some sort of response anyway. So I think that might even be worse. Would you suggest that we just drop the connection silently and don't answer at all? If this is so, then maybe the draft should say something about this. There could be false positives and clients should be aware that this can happen. I proposed the dedicated code because I figured we could bounce this back when we see the same IP hammering us, without having to inspect the actual request (which requires validating the CMS etc). However now that I think about it a bit more, this would still require that we generate a CMS for the response... So to conclude: I think I would prefer an http status return in this case to minimise server processing power. Maybe something similar to validation failure in paragraph 3.2: HTTP 400 Bad Data What do you think? Cheers, Tim _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
