Re: little problem with <close-session>

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Eliot Lear" <lear@cisco.com>
> To: "Margaret Wasserman" <margaret@thingmagic.com>
> Cc: "netconf" <netconf@ops.ietf.org>
> Sent: Thursday, August 19, 2004 11:37 AM
> Subject: Re: little problem with <close-session>
...
> 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.

You may not want it, but it may be unavoidable.
Consider cases like power failure or removal of
the card where the nonvolatile store lives.
The question is whether there's any value to having
the protocol reflect these nasty cases, when there's
always going to be the possibility that the "last gasp"
might not make it to the wire.

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

The concern is independent of whether command processing
is synchronous.  The protocol (section 3.6) does not require
the manager to wait for a response before sending the next command.
The question is about what the agent should do with buffered commands
if an attempt to send a response fails because the other side
(in "fire and forget" mode) has closed the connection.  Regardless of
whether the protocol has a "close" PDU, the behaviour needs to be
defined.  (I.e., are commands processed after the manager initiates
a transport layer close?)

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

I think the concern is not about a possible attack, but rather about
resource consumption on the manager when it needs to talk to a large
number of devices consecutively.

Randy



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