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

["Jim Sermersheim" <jimse@novell.com>]

After reading this thread, I conclude that there is some confusion
regarding the wording in section 4.14.3.2. Is that correct? Even then,
I'm not sure what the confusion is. To me it says that TLS may be
abruptly removed by closing the transport connection. And by the way, if
the server is about to do this, it may send a Notice of Disconnection
first.  I'm not even sure what use this section is, it seems obvious to
me - one can abrupty stop _anything_ by closing the transport
connection. I suggest removing the section.

The other thing that may have raised its head on this thread was Kurt
suggesting that Notice of Disconnection be followed by graceful closure
(as is done with Unbind) rather than an abrupt closure of the transport
connection. I'm thinking or hoping I mis-interpreted that. I think
RFC2251 and all revisions of [Protocol] have been clear that
transmission and reception of Notice of Disconnection is always followed
by an abrupt (not graceful) closure of the transport connection.

Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 12/8/04 1:32:38 PM >>>
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