How does kill-session affect physical connection for SSH and TLS?

NETCONF
1

Hi,

We are testing with confd using both SSH or TLS.

The scenario is that we create two connections (either SSH or TLS). Both has same protocol.

Then we get the session ids for each eg. ID 1 and 2 for each one.

Then in our client we call:

netconfSession1.killSession(2);

so we kill NETCONF session for the other connection.

We can see the is sent for the session and
ww get a in rpc reply.

Now here is the difference:

  1. For SSH, transport is also closed not only NETCONF session. So we have no connection more.
  2. For TLS, transport is not closed only the NETCONF session. We still have a connection.
    I can see from our client, it is sent a “alert write:warning: close notify” but nothing that indicates
    server responding to this. According to protocol there should be a close handshake to avoid
    “man in the middle”-attack.

This is the RFC ,rfc6241, for kill-session.

Description:  Force the termination of a NETCONF session.

      When a NETCONF entity receives a <kill-session> request for an
      open session, it will abort any operations currently in process,
      release any locks and resources associated with the session, and
      close any associated connections.

      If a NETCONF server receives a <kill-session> request while
      processing a confirmed commit (Section 8.4), it MUST restore the
      configuration to its state before the confirmed commit was issued.

      Otherwise, the <kill-session> operation does not roll back
      configuration or other device state modifications made by the
      entity holding the lock.

Questions:

  1. How do you interpret the NETCONF spec. Should physical connection be closed too?
  2. How is it implemented for both protocols in ConfD? What can we expect with physical connection when doing a kill-session?

br,

//mikael petterson

2

Hi,

Since ConfD doesn’t have a built-in TLS server, I assume that you are using a “netconf-subsys” program for a TCP connection as a relay between your TLS server of choice and ConfD.
Check that your netconf-subsys application handle closed connections from ConfD properly.

See ConfD UG for more on “netconf-subsys” programs and this demo for a GnuTLS NETCONF subsys demo:

Best regards