Subject: Re: protocol: session termination

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 11 Feb 2005 14:32:14 -0700

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 <[email-masked]> 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