Re: protocol: session termination

At 10:03 AM 2/11/2005, Hallvard B Furuseth wrote:
>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.

(See my note regarding progression of this I-D in my response
to your "protocol: closing SASL upon Unbind" thread.)

The server may initiate closure the LDAP session at any time.
This closure may do so graceful or aburpt.  Graceful termination
implies that the server teardowns each layer in an orderly manner,
starting by sending a notice of disconnect at the LDAP
message layer.  Aburpt termination implies that the server
immediately ceases communications with the client at all layers
within the LDAP session.  This is appropriate where it would
be precarious to continue further communications.

>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".

In this scenario, the server should initiate gracefully close
the LDAP session by sending a Notice of Disconnect indicating
the reason for that closure, the proceed with tearing down the
LDAP session in an orderly manner.

But the quoted text is talking about the scenario where the
server feels it is precarious to communicate further with the
client within the LDAP session (or layer thereof).  In this
case, the server is to cease transmission at all layers of
the LDAP session and close the underlying connection.

>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.

I wonder why you think abrupt closure of the LDAP session would
involve transfer of an LDAP PDU.

>When it's maybe not an attack, I think the server should inform the
>client of why it's terminating the session.

If the server can safely do so, it should.  The text, I believe,
simply indicates that a server where further communication would
be precarious, the server may abruptly terminate those communications.

>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?)

Aiding an attacker is also not the purpose of the notice.  If
sending a notice and/or gracefully teardown installed layers would
aide an attacker, the server should abruptly close the underlying
connection.  (And, I note, if sending a TCP RSET would aide
the attacker, the server may choose to terminate the session
by other means (ICMP) or simply cease ALL communications.

>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.

As noted above, abrupt closure is for when it would be
precarious to communicate the reason for disconnect (or
to otherwise communicate).

>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.

I think it somewhat pointless to argue whether or not the notice
is part of the closure or not.

Instead, consider the following in termination of the LDAP session.

If further communication would be precarious, then the implementation
(client or server) should cease communications.  Period.  

If further communication would not be precarious, then the
implementation (client or server) should teardown the LDAP session
in a graceful manner, starting by sending an appropriate LDAP message
(Unbind for clients, Notice of Disconnect for servers) and then by
tearing down any installed security layer (taking advantage of
truncation attack detection in the layer), then by closing the
underlying connection.



>-- 
>Hallvard