Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt

[Kent Watsen <[e-mail]>]

Hi Tom,

>The biggest difference is that 5539-bis never talks about reverse-TLS
>because TLS is not reversed; NETCONF client = TLS client, NETCONF server
>= TLS server always - simple, straightforward.

With SSH, it is also always the case that the NETCONF client = SSH client,
and the NETCONF server
= SSH server.  Please take another look at 5539-bis, section 2.1.3, as it
regards the call-home case and it's definitely the case that TLS is
reversed in exactly the same way that SSH is in the reverse-ssh draft.
The two are very consistent in this regard.


>So why does reverse-ssh talk about reverse-ssh when ssh is NOT reversed?
>To confuse people and raise hackles?  I know, times past we - or at
>least I - was really talking about SSH role reversal but now we are not.

SSH *is* reversed or, more specifically, the directionality of the SSH
transport on top of its TCP transport is reversed  (same way as with the
TLS-based call-home).  The best way to fix the consistency issue with the
drafts is to merge reverse-SSH into rfc4742  (i.e. rfc4742bis).


>Keeping the term reverse-ssh I think politically unwise since we know it
>rings alarm bells with those who know the security properties of SSH.
>It confuses those who were not around when we really were discussing it,
>since the term is technically wrong.  It makes ssh call home sound
>completely different to TLS call home, which will confuse even more
>people.  And it leads to section 5 which, since the usage of SSH is
>identical to that of RFC4742, effectively updates RFC4742.

Perhaps, I don't know.  As it stands, "reverse ssh" is pretty well known,
but we certainly wouldn't want  ssh call home to sound completely
different to TLS call home...



>So, make it RFC4742bis?  Could do, or have done so, but I do not think
>it necessary.  Rather
>- change the terminology from reverse-ssh to call home
>- specify that it updates the security considerations of RFC4742 by
>fleshing out what is acceptable verification and authentication in the
>Security Considerations of RFC4742
>- point to 5539-bis for the rules on X.509 cert checking when certs are
>used for identification - I think that 5539-bis does a good job there
>which reverse-ssh s.5 does not
>- provide text on security checking with raw host keys (as in current
>section 5), since that is SSH specific; netmod-system has something on
>this but probably not enough.

It's good to have a concrete list of suggestions to work off of, thanks.
These are fairly extensive changes, before jumping in and doing it, how
does this look to everyone else?



>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


>The rod we make for our backs is to introduce functional enhancements as
>part of a data model, not something the IETF has tended to do in the
>past; rather the function has been sorted out first as text, or
>pseudo-code or some such, and then the data model has been created to
>support it i.e. we should not be introducing new function in
>netconf-server, as if having a data model is all we need.

I agree with the statement, but disagree that it applies here  (with the
caveat that we add some explicit text into 5539bis and reverse-ssh draft
about heartbeats).



>This also means that whether or not something is optional in the data
>model is irrelevant.  The question should be, does it make sense, in
>future, to implement NETCONF over SSH or TLS while being completely
>ignorant of periodic connections, heartbeats, reconnection, timeouts
>because they are only in netconf-server which is only a passing,
>Informative Reference, nothing you need to know about?  If
>netconf-server progresses with something like its current contents, then
>I think my answer is apparent.

For reverse-ssh, I think it's Informative, as it truly is an optional
data-model (see above)

For 5539bis, there may be a need for a Normative reference, but only
because of the psk-maps and cert-maps, which *might* get moved to the
netmod-system-mgmt draft.



>Given the xml, I would be willing to edit the reverse-ssh I-D changing
>all references to 'reverse-ssh' to 'call home' leaving the rest of the
>text unchanged pro tem.  I feel that strongly about it.


I appreciate the offer and gladly accept it, but let's wait to hear if
anyone has objections, or if we plan to merge reverse-ssh into a 4742bis.


Thanks,
Kent