Subject: little problem with <close-session>

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Aug 2004 09:47:31 -0700

The manager is meant to issue a <close-session> element to initiate a 
close.  For BEEP this is a bad idea, and it's probably a bad idea for 
everyone else as well.  The problem is that either side should be able 
to initiate a close.  This is particularly necessary for orderly 
shutdown of the device running the agent.

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.

Eliot

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

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 18 Aug 2004 18:42:21 -0400

Hi Eliot,

Maybe you are right, but I have some thoughts...

At 9:47 AM -0700 8/18/04, Eliot Lear wrote:
>The manager is meant to issue a <close-session> element to initiate 
>a close.  For BEEP this is a bad idea, and it's probably a bad idea 
>for everyone else as well.  The problem is that either side should 
>be able to initiate a close.  This is particularly necessary for 
>orderly shutdown of the device running the agent.

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

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

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Aug 2004 11:37:02 -0700

Hi Margaret,
> 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:
> 
> 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 
> 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.

> If we put this in the application mapping, how would you suggest that 

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 19 Aug 2004 13:17:26 -0700

Hi -

> From: "Eliot Lear" <[email-masked]>
> To: "Margaret Wasserman" <[email-masked]>
> Cc: "netconf" <[email-masked]>
> Sent: Thursday, August 19, 2004 11:37 AM
> Subject: Re: little problem with <close-session>
...
> 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.

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

> 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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Aug 2004 16:25:54 -0400

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

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

> number of devices consecutively.

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

Eliot

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 20 Aug 2004 14:34:26 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Sent: Friday, August 20, 2004 1:25 PM
...
> command, you've gone nuts.

That's not the case we were worried about.
The scenario is where a manager sends one
or more commands, and then closes the connection
without waiting for the response(s).  The agent will
be able to read the (buffered) commands, but will
get an error when it tries to send the responses on
the closed connection.  Regardless of whether we think
this is a smart thing to do, we need to define what happens.

> But this is only half the problem- the other
...

I think we're in violent agreement on this point.

Randy

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 21 Aug 2004 06:21:25 -0400

Hi Eliot,

>>  for the manager to be the one that initiates the TCP-level close, so that

s/manager/agent

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

What is a "meta command"?

>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 am not talking about an attack, I am talking about normal operation.

As you may recall, one of the serious problems with HTTP 1.0 was that it
opened many TCP connections and left the connections in TIME-WAIT
state on the server (because the server would close the connection to
indicate end-of-file).  Because there was one server and many, many
clients, the server would eventually run out of resources.

In our protocol, there is likely to be one manager and many, many
agents.  Therefore, we need to be careful that any state (such as
TIME-WAT state) that is left behind after a session completes remains
on the agent, not on the manager.

So, it is important that all TCP connection closes are initiated by the
agent, so that the agent will end-up with the TIME-WAIT state.  And,
I consider <close-session> to be a good way for the manager to ask
the agent to initiate a close.

Can you explain what problem <close-session> causes?

I don't understand what the existence of <close-session> has to do
with the fact that we don't have the ability for the agent to send
commands to the manager.  I understand that the agent might close
the session in mid-session if the agent is shut down, but that will
typically result in a reset and wouldn't be considered normal
operation.  It is also possible that an agent or manager will crash
(go away without closing or resetting the session) or that the agent
will become unreachable from the manager (and/or vice versa) due
to network problems that are unrelated to either the manager or
agent...  Implementations will need to handle those conditions.

Do you think we need to add text to the base spec explaining
what happens in such abnormal close conditions?  I'm not sure this
is needed to write interoperable implementations, but perhaps it
would address your issue of what happens when the agent needs
to close the session?

Margaret

---

From: Eliot Lear <[email-masked]>
Date: Sun, 22 Aug 2004 20:49:52 +0200

Margaret,

What I meant by a "meta-command" is something that is sent in the 
mapping but not otherewise part of the netconf protocol. 
<close-session> in the BEEP mapping could simply be a CLOSE 0.

My motivation is simple- the agent should be able to initiate an orderly 
close, just as the manager would.  Now, if we don't add this into the 
protocol, the BEEP mapping will simply do the normal BEEP thing to close 
a BEEP session.  It certainly will NOT send an RST unless the close was 
not orderly ;-)

BTW, in my mind the manager is likely to keep connections up for long 
periods of time.  I realize this is only one model of operation, though.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sun, 22 Aug 2004 21:00:42 +0200

> this is a smart thing to do, we need to define what happens.

ahh... okay, I think we have been miscommunicating.  I don't propose 
that the BEEP application mapping close the transport connection until 
all responses are received.  As it receives those responses it can ACK 
them at the TCP level.

N.B. in BEEP the initiator always initiates the transport close.  This 
may be a problem, given Margaret's concerns, but <close-session> doesn't 
address that part at all.

Eliot

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 23 Aug 2004 05:52:54 -0400

>N.B. in BEEP the initiator always initiates the transport close.  This may be
>a problem, given Margaret's concerns, but <close-session> doesn't address
>that part at all.

When the initiator initiates a BEEP-level close, does that mean that 
it will also initiate the TCP-level close (by sending the first 
<FIN>)?  If so, I think that this may cause a potentially serious 
problem with the scalability of NETCONF over BEEP for managing very 
large numbers or nodes and/or handling large numbers of 
separately-initiated transactions, as the side of the TCP connection 
that sends the first <FIN> will also be the side that ends-up with 
connections in TIME-WAIT state for a couple of minutes after each 
session is closed.

Perhaps, given the capabilities of workstations and/or some 
enhancements to the TCP protocol this is no longer a serious problem? 
I know that it was a serious problem when HTTP 1.0 was introduced -- 
in that case the TIME-WAIT connections were left on the server and 
this required very high-end servers to handle large numbers of HTTP 
connections.  I am surprised, based on that experience, that BEEP 
doesn't offer a way for the two ends of the session to 
negotiation/control who will initiate the TCP portion of the close. 
Is BEEP specifically tailored for use in cases where there will be 
many clients and few servers?  In NETCONF we have the opposite 
situation -- one (or a few) client(s) and many servers.

Anyway, maybe we should check with some transport-saavy folks to see 
if this is still an important consideration for protocol design?

Margaret

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Aug 2004 14:04:27 +0200

On Mon, Aug 23, 2004 at 05:52:54AM -0400, Margaret Wasserman wrote:
 
> connections.

To we envision short lived netconf connections? I mean, in HTTP 1.0,
you had a separate connection for every little icon or other gimmick.
Do we expect that same for netconf? I would hope not.

On the other hand, lazy script writers might produce exactly this
kind of thing (and most of them will not bother about nice cleanups
and just call "exit" or whatever). 

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Aug 2004 14:57:48 +0200

Margaret,

My goof.  I misread the RFC.  It is based on who requests the close (the 
other guy then closes).  So if the agent wants to close, the manager 
would initiate the close.  On the other hand, in the case you are 
concerned about, as currently written, when the manager wants to close, 
it would be the agent that initiates the close.

RFCs in question are 3080 and 3081.  3081 has the TCP mapping.

I'd like to understand how much the CLOSE_WAIT concern is real.  The 
problem with HTTP 1.0 is that each site would create tens of connections 
to retrieve a page.  In addition, sessions were VERY short lived.  Will 
either of these cases be generally true?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Aug 2004 15:01:40 +0200

> and just call "exit" or whatever). 

Yah, presumably that's okay as long as they don't repeatedly hit the 
same element in a rapid-fire sort of way.

Eliot