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

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

At 04:18 PM 1/20/2005, Jim Sermersheim wrote:
>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.

Then the server is not abruptly closing the connection.

I understood the existing specification to allow two options
for server initiated closure:
        1) abrupt closure: close the transport;
        2) graceful closure: send notice of disconnect,
           tear down SASL & TLS, then close the transport

Likewise, the client has two options to initiate closure:
        1) abrupt closure: close the transport;
        2) graceful closure: send unbind request,
           tear down SASL & TLS, then close the transport

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

Right.

And if you are sending a PDU before closure, then you obviously
are attempting graceful closure.

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

I took Notice of Disconnect and Unbind to cause server-initiated
and client initiated, respectively, graceful closure of the
LDAP session.

The confuse may be due to the fact that RFC 2251 was written,
as I see it, without SASL and TLS in mind.  And then 2830
adds some confusion it has one optionally sending a PDU
during what it calls abrupt closure.

I think we need to use the term 'abrupt' to be mean, as the
term is generally used in application layer protocols, that
the transport layer immediately without additional transfer
of application layer data.

I think we should also use the term 'graceful' to mean, as the
term is generally used in application layer protocols, that
the protocol stack is torn down in an orderly fashion.



>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