Subject: SSH channels

From: Martin Bjorklund <[email-masked]>
Date: Mon, 17 Jul 2006 19:33:49 +0200 (CEST)

Hi,

At the interim we briefly discussed whether NETCONF supports multiple
SSH channels as "a well hidden feature".

In draft-ietf-netconf-ssh-05,txt, section 5 implies that multiple
channels are not supported (at least not very cleanly), since it
explicitly states that when an agent receives a <close-session>, it
shall terminate the SSH session and the TCP connection.

(So theoretically one could try to open multiple netconf sessions over
new ssh channels over the same ssh session, but as soon as one of the
netconf sessions sends <close-session>, all these netconf sessions
will be torn down.)

/martin

--
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: Andy Bierman <[email-masked]>
Date: Mon, 17 Jul 2006 10:45:42 -0700

> netconf sessions sends <close-session>, all these netconf sessions

thanks -- this is the exact text, and I also remember clearly
that when the WG took out multiple conceptual functional channels
at the RPC layer, we decided to hide it, and support them later
in the transport layer instead.

> /martin

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 17 Jul 2006 15:47:48 -0400

>shall terminate the SSH session and the TCP connection.

I don't see this.  Section 3 of draft-ietf-netconf-ssh-06.txt reads:

   After the ssh-connection service is established, the client will open
   a channel of type "session", which will result in an SSH session.

So the "SSH session" refers to the SSH channel of type "session".

Then in Section 5, we have:

   ... When the agent processes a <close-session>
   command, the agent shall respond and terminate the SSH session.  The
   agent MUST NOT process any RPC commands received on the current
   session after the <close-session> command.

If you see the use of netconf over a distinct channel as a distinct
netconf session, then the close-session on one would not affect the
other.  You get this for free with openssh, since the ssh daemon spawns
the subsystem as a child process, cleaning up when all children have
been reaped.  If you start two netconf subsystems, sshd will continue
until both have died.

The other reading would mean that <close-session> would need to kill
the parent sshd.  Even so, if the only thing blocking this is the close
RPC, we could fix the close RPC.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 Jul 2006 13:16:43 -0700

> RPC, we could fix the close RPC.

Fair enough.
Like almost every thing else in this protocol,
there are usually multiple passages to cite that may be
interpreted in particular ways that support many viewpoints
on the same complex problem.

(Like another book I know of, but that's out of scope ;-)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Jul 2006 18:57:07 +0200 (CEST)

> So the "SSH session" refers to the SSH channel of type "session".

You're right.  I looked at an old version of the draft...  sorry about
that.

Furthermore, section 5 says:

   To continue the example used in previous sections, an existing
   NETCONF subsystem session could be closed as follows:
           ^^^^^^^^^^^^^^^^^

> RPC, we could fix the close RPC.

So, I also think that the draft should be read as mapping one SSH
channel to one NETCONF session.

(Which, as you pointed out, makes it easier to use OpenSSH, since this
is it's default behaviour.)

/martin

---

From: "tom.petch" <[email-masked]>
Date: Thu, 20 Jul 2006 14:50:51 +0200

I came across
 draft-cain-logging-caps-00
and found it is actually all about notifications, written as part of opsec.  It
interests me because it gives an operator perspective, as opposed to a software
developper perspective, of what notifications are about.

As the name implies, it only considers the use of syslog, and that only in the
shape of [RFC3164] and [RFC3195].  I am surprised at the lack of reference to
SNMP, less so to syslog-sec or netconf.

But its existence does emphasise for me the importance of this topic (even if
the IETF does not quite know what to do with it:-)

Tom Petch