[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: little problem with <close-session>



Randy Presuhn wrote:

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.

I agree, it may be unavoidable. But in an orderly shutdown it is avoidable, and we should provide guidance on that (hopefully) general case.

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?)

My answer is NO. If you send a close and then send an additional command, you've gone nuts. But this is only half the problem- the other half is that the agent cannot initiate the close, and it should be able to. Consider the very basic case of a reconfiguration requiring a re-authentication. The only way to do that is to close the connection. We need an orderly way to do that.



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


Fair 'nuff.  It's possible in the BEEP application mapping.

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