|
In an earlier discussion on this topic, Kurt made the observation that RFC2251 was not actually prescribing abrupt closure in a number of places where it said things like "close the connection". When it was written, there was no notion (in the document) of a SASL or TLS layer. Closing the connection was as graceful as it got. Viewing it that way, I saw the distinction between graceful and abrupt closure, and the suggestions of when to do which as clarifications rather than substantial changes.
If I'm wrong, and we've actually changed the behavior, then I do need to add that to the changes section.
Let me know if you think there are instances where we've changed behavior.
Jim
>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 2/11/05 11:03:26 AM >>> I'm sorry about dropping these threads - I seem to be suffering from "standardization fatigue":-) I just haven't been able to sit down and look at this. So I'm sending a few comments before dashing off on a week's holiday, and I guess I'm not promising to follow any detailed resulting discussion anyway... This is definitely a 'feel free to ignore it'-kind of posting. While comparing protocol-30 with -20, I noticed: - Servers can or must use graceful closure instead of abrupt in some cases. That doesn't seem to be reflected in the Changes appendix. - A new paragraph: > 6. Security Considerations > > In the event that a protocol peer senses an attack which in its > nature could cause damage due to further communication at any layer > in the LDAP session, the protocol peer should abruptly terminate the > LDAP session as described in Section 5.3. While this is good by itself, I think an at least as common scenario is that it senses something which _might_ an attack, but might be something else - e.g. a client error - which it would be useful for the client to know about. E.g. a revoked client certificate, or probably some of the reasons for inventing the dreaded "invalidated associations". I wonder if that's why I wanted Notice of Disconnection followed by abrupt closure while Kurt did not, if Kurt was thinking more of events that are clearly attacks. When it's maybe not an attack, I think the server should inform the client of why it's terminating the session. After all, the purpose of the Notice is to "assist clients in distinguishing between an exceptional server condition and a transient network failure". And when it maybe is an attack, the session should be terminated abruptly rather than gracefully (since graceful closure might surrender the connection gracefully to an attacker so that he could continue the session. Did that discussion go astray?) Or I suppose it could be an attack of a kind which might not be able to prevent the server from informing the client of this. Then it would certainly be useful to inform the client of the attack. Someone also spoke of Notice of Disconnection as part of the closure. I can see that from that point of view it can be un-nice to have it in the middle of an abrupt closure, at least. I always always thought of it as an alert sent before the closure, not as a part of it. -- Hallvard |