Re: little problem with <close-session>

[Eliot Lear <lear@cisco.com>]

Hi Margaret,
> <close-session> is really a way that the manager can ask the agent to 
> close the session.  Its existence does not, necessarily, stop the agent 
> from closing the session at other times, I suppose.

But we haven't defined how to do that.  I can easily define how to do 
that in the BEEP mapping, but since we don't have the agent sending 
commands, I don't really know how to do it at the NETCONF protocol level.



> There are two 
> reasons why I think that this is cleaner than having the manager simply 
> shut down the connection
> when it is finished:
>
> (1) The <close-session> command will be processed in-band, like any 
> other command and the agent can close the session when it is finish 
> processing all commands, freeing all locks, etc.  

All I am saying is that how this happens needs to be specified in the 
application mapping document and NOT the base protocol.  See my current 
draft.  I provide guidance specifically on how locking is handled.  For 
instance, you don't want the agent initiating a close while it is locked.

> This avoids any 
> ambiguous cases where (for instance) the manager finishes and closes 
> down before the agent has finished processing all of the commands. After 
> receiving an error when trying to respond to one command, should the 
> agent continue to read from the connection and process subsequent 
> commands from the manager?

Since commands are synchronous, I don't see the problem.

> (2) For TCP-based session-layer protocols, it is (IMO) highly desirable 
> for the manager to be the one that initiates the TCP-level close, so 
> that the TIME-WAIT state ends-up on the agent side.  A manager may 
> manage a very large number of devices and need to connect to all of 
> those devices in rapid succession, while it seems less likely that an 
> individual device will be reconfigured as often.

Think about a meta-command, then.  I can already do this in the BEEP 
mapping, and can control which side disconnects first.  But putting that 
aside, in the case of an attack (which is what I think you're concerned 
about), the device is going to close unauthenticated connections as a 
defensive mechanism, no matter what the protocol says.

> > This argues *strongly* for the removal of <close-session> and 
> > returning this function to the application mappings.  If we need to 
> > add some meta-thing into SSH, so be it, but the agent needs to 
> > initiate the close - somehow.
>
>
> If we put this in the application mapping, how would you suggest that 
> would work?

For BEEP it's easy, there are protocol semantics to close a connection. 
   You tell me for SSH.  What are the protocol semantics to close a 
connection?  Same deal with HTTP.  If you need to signal to the manager 
to close the connection, perhaps a meta-command within the mapping. 
Nothing prevents such a thing, and the code to do so would be small.

Eliot

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>