Subject: [Netconf] RESTCONF #2: session monitoring

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Nov 2014 10:17:50 -0800

Hi,

There are some unresolved issues related to basic RESTCONF
session monitoring.  The WG agreed to define a "restconf-tls"
identity that can be used for the 'transport' leaf in the
NETCONF "session" list.

Some solution options from here:

S1)  do nothing; let vendors populate session entries and increment
counters any way they want

S2) specify some details like which counters to increment, but
let vendors decide how to determine a session that should
be added to the list

S3) specify all details including how to determine a session that should
be added to the list

Issues:

I1) the server may not be able to detect persistent connections
depending on the implementation. Is it possible to define S3
without considering implementation details?

I2) the server needs to create the session monitoring entry
right away, on the first request.  The session may only last 1
request/response pair. Is this an issue?

I3) RESTCONF is not designed to support or require the server
to maintain session state. (Not REST-ful, remember?)
A server should only be required to maintain sessions for
a single request (where SSE long-poll notifications counts
as a single request).

I4) should the RESTCONF server only create session
entries for long-lived SSE sessions?

I5) should the server send netconf-session-start and
netconf-session-end notifications for RESTCONF sessions?

Comments:

We need all RESTCONF sessions to get a session ID, show up
in the monitoring and audit logs, because the configuration
can be edited by RESTCONF.  The netconf-config-change
notification is always sent if RESTCONF changes the running datastore.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 26 Nov 2014 20:41:39 +0000

OK, I realize my folly in hoping we could leverage the TLS transport-level
connection to derive a session.  In particular, it fails if all the TLS
connections are terminated by a load-balancer fronting a rack of HTTP-only
application servers.

So the next thing is if RESTCONF can leverage a cookie to derive a session
(session exists so long as cookie is valid).  Note the abstract for RFC
6265 (HTTP State Management Mechanism) says:

   This document defines the HTTP Cookie and Set-Cookie header fields.
   These header fields can be used by HTTP servers to store state
   (called cookies) at HTTP user agents, letting the servers maintain a
   stateful session over the mostly stateless HTTP protocol.

   ^^^^^^^^^^^^^^^^^

This StackOverflow response is notable: http://stackoverflow.com/a/6068298

Also notable: 
http://www.kaleidos.net/blog/295/stateless-authentication-with-api-rest/

So, for S3, it seems the choices are:

  K1: do nothing
  K2: use a cookie for session-tracking only (not auth),
      assume BasicAuth is mandatory-to-implement, but allow others
  K3: use a cookie for both auth and session-tracking,
       - RESTCONF would define specific login/logout resources

Anything else?

Kent

On 11/26/14, 1:17 PM, "Andy Bierman" <[email-masked]> wrote:

>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Nov 2014 14:17:08 -0800

>    stateful session over the mostly stateless HTTP protocol.

The original task was simply to identify SSE sessions because
these are the only long-lived RESTCONF "sessions".

We currently store all RESTCONF sessions in the session list,
because the server instrumentation can block, so even a 1 request
session can be a long-lived session.  In the multi-threaded build,
other sessions will still be running, and the RESTCONF session
will be visible.

IMO it is OK if a server treats 1 request as a session or N requests
as a session, so picking S2 is good enough.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 26 Nov 2014 23:14:13 +0000

>these are the only long-lived RESTCONF "sessions".

Tracking just SSE sessions is so non-intuitive and somewhat pointless.
What people want is some means to be aware of all the different "sessions"
going on, not just the never-ending responses.  I know we're struggling
with the stateless-server constraint, but the articles I linked before are
pretty pragmatic.

>other sessions will still be running, and the RESTCONF session

You mean that each REST API entry point is something like this:

    Foobar() {
      session_id = start_session();

      // do bis logic here

      close_session(session_id);
      return HTTP_response;
    }

So even short-lived responses show up as a session temporarily?

>as a session, so picking S2 is good enough.

Assuming cookies are needed to track sessions correctly, there would be a
requirement for clients to implement the "Set-Cookie" and "Cookie" header
fields from RFC 6265.   Can we at least say that servers MAY use cookies?
(i.e. clients MUST support)

Having been thru a Common Criteria certification before, I'm painfully
aware that every login and logout event needs to be logged, in addition to
the actions performed.   Without some form of a session, my understanding
is that BasicAuth leads to 2/3-rds of the audit log being "login" and
"logout" events, which doesn't match common expectations.  Others must
have experience with this, should we ask the Apps folks for advice?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Nov 2014 15:40:55 -0800

> So even short-lived responses show up as a session temporarily?

yes (except the response is sent before the session is closed)

> (i.e. clients MUST support)

IMO it should be left as an implementation detail.
If not, then we should stick with the original decision to
not have any standard RESTCONF session monitoring at all for now.

> have experience with this, should we ask the Apps folks for advice?

OK -- we record username and timestamp + edit details.
The session-id number is not very interesting.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Nov 2014 08:12:53 -0800

Hi,

There doesn't seem to be much interest in this issue.
The original WG decision is to just define a "restconf-tls"
identity for the session "transport" leaf.

IMO the original consensus of "punt this until later" is confirmed.
That would be solution S1.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Nov 2014 08:23:40 -0800

> with the stateless-server constraint, but the articles I linked before are

I don't think tracking SSE sessions is pointless, especially since the
client has to initiate a "create-subscription" to receive notifications.
If the operator wants to reboot the server, it might be good to know
what SSE sessions are going to be terminated.

I suppose the entire notion of RESTCONF sessions is non-intuitive,
because only the server knows there is a session going on.
Unlike NETCONF, the client does not actually start or close an
application layer session.

Andy