Re: server-initiated connection closure vs. TLS/SASL closure (was: closing SASL upon Unbind)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:56 AM 12/8/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 09:10 AM 12/8/2004, Hallvard B Furuseth wrote:
>>>Kurt D. Zeilenga writes:
>>>> My previous suggestion does not adequately cover the
>>>> issue of graceful closure of the LDAP session.  That is,
>>>> the reason why a particular order was suggested was that
>>>> it was thought to be graceful.  So while I have no
>>>> problem with removing the ordering aspect of the current
>>>> text, I'd like to indicate that Unbind/Notice of Disconnect
>>>> are intended to affect a graceful closure.
>>>
>>> Actually, this thread started with the text for the Unbind operation,
>>> not Notice of Disconnection.
>>
>> I just noticed that the Notice of Disconnect section does not
>> include symmetric text to Unbind.  As previously discussed,
>> it should (but updated per this discussion).
>
>Which discussion was that?  It reached the opposite conclusion of mine
>just now.
>
>>> [Protocol] states that Notice of
>>> Disconnection should use abrupt closure, not graceful, when the TLS
>>> layer is removed.  It seems to say the same when the connection is
>>> closed for other reasons, but maybe I'm seeing too much in these words.
>>
>> What I thought it meant was "In this circumstance, a server MAY
>> send the client a Notice of Disconnection before closing the
>> transport connection AFTER abruptly closing TLS."  This makes no
>> sense as there is no way to re-establish PDU alignment after
>> an abrupt closure.
>
>There is no way to send anything after abrupt closure.
>
>> If instead it was meant, "In this circumstance, a server MAY
>> send the client a Notice of Disconnection before closing the
>> transport connection BEFORE abruptly closing TLS", this would
>> make little sense as that requires further use of TLS.
>
>It should be 'In the case of server initiating closure,...', but with
>that addition I don't see a problem with it.

But this section is talking about abrupt closure.  Not only
does it makes little to no sense to send a Notice of Disconnect
before an abrupt closure.

>The connection may be compromised and the Notice may not reach the client,
>but in most cases it probably will.

If the connection is compromised, one should cease sending
additional TLS data (period).

If the event is of a nature were abrupt closure is appropriate,
then the connection should be abruptly closed (no transmission
of any application-level (including PDUs, SASL cipher buffers,
or TLS frames) data.

If the event is of a nature where graceful closure is appropriate,
then the implementation should gracefully close the LDAP session
in an orderly fashion.  This should be initiated by queuing
an Unbind or Notice of Disconnect (depending on which peer is
initiating) for transfer, closing the queue, allowing the
queue to drain, allowing the SASL layer to drain (per the
SASL and the SASL mechanism specifications), allowing TLS layer
to drain (per the TLS and TLS ciphersuite specifications),
and then closing the transport connection (per the transport
protocol specification).  It's noted that graceful closure
of the layers before the PDU layer may involve exchange
of data beyond that necessary to transfer the last LDAP
PDU.  For instance, TCP requires a specific closure exchange.
These should not be skipped during graceful closure.

Kurt