[Netconf] periodic connections, heartbeats, reconnection, timeout was Re: WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt

[t.petch <[e-mail]>]

Snipping out the issues of terminology and security

----- Original Message -----
From: "Kent Watsen" <[e-mail]>
To: "t.petch" <[e-mail]>; "Bert Wijnen (IETF)"
<[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, April 10, 2014 10:55 PM

>The other grey area is that netconf-server introduces periodic
>connections, heartbeats, reconnection, timeouts.  All good transport-ey
>stuff which impacts both SSH and TLS transports and, at least for
>heartbeats and probably for more than that, needs protocol specific
>details.  I think reverse-ssh and 5539-bis incomplete if netconf-server
>includes these features and the other two do not at least reference
>them; which makes netconf-server a Normative Reference.

All but heartbeats don't require interoperability.   It was mentioned in
London that Heartbeats were under-specified.  For SSH, heartbeats are
done
within the existing SSH protocol, so there is nothing for an NMS to do
special in order to reply to heartbeats from a device, but I'm perfectly
OK with calling it out explicitly in the reverse-ssh draft.  For TLS,
heartbeats depend on rfc6520 (e.g. run a OpenSSL version 1.0.1 or
greater*), which *needs* to be called out in 5539-bis.  Once how
heartbeating is needed and is implemented is called out in both drafts,
then I believe NMS/device interoperability can be achieve, without a
Normative reference to netconf-server-model.   For instance, the NMS
doesn't need to know if the device's connection is periodic or a
reconnection, or if it was disconnected due to a timeout - all that
state
is solely on the device side.  Thus I still think that the
netconf-server-model is optional to support and hence should be
Informational.

* or the very very latest if you want to avoid the recent "heartbleed"
bug

<tp>

ssh-server introduces introduces periodic connections, heartbeats,
reconnection and timeouts, all good functions to have in a transport
protocol.  There is at least some impact on 5539-bis, perhaps on
reverse-ssh, but the starting point that I would like clarified is a
question of scope.

Reading the details, I struggle to see why these functions should be
tied to
 - SSH
 - TLS
 - listen
 - call home
 - NETCONF client
 - NETCONF server
That is, why shouldn't any NETCONF engine send a heartbeat, timeout if
no response in a suitable period, drop a connection and reconnect when
it wants to?  These functions seem useful in any setting, rather than
specific to a particular scenario.

So, as and when this I-D is put up for adoption by the WG, I would like
that to be clarified before the I-D is adopted, not after.  What is the
scope, what is the applicability of these new transport functions?  Not
what the I-D currently says, I can see that, but where do we want to end
up?

This then has consequences.  Do we, for example, need a different
message for 'I am closing in the normal fashion' v 'I am closing for a
timeout' (tricky -  long established protocols are still wrestling with
this one) v 'I am closing pro tem but expect to return when I have
something to do'?

(And may be the answer is that we do not want to progress all of these
functions at this time).

Tom Petch

Thanks,
Kent