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

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 03 Apr 2014 13:36:47 +0200

WGLC period ended last Tuesday (April 1st).

Kent, where are we with this one?

Do you expect to post a rev 04 that addresses all comments we have received?
Either WGLC comments or other comments? Once that is done, I would like to ask:
- Kent to post which comments have not been addressed and why (if any)
- If possible, Kent to post a summary of changes (although that may already be
   in the document, and that is fine too).
- All those that made comments to check if they are OK with the way that
   they have been addressed or responded to.

Bert

On 27/03/14 17:02, Kent Watsen wrote:
>
> Hi Alan,
>
>
> Awesome comments - thanks!
>
>
> I applied all fixes mentioned below to my working copy of what will be
> -04, so you'll have to wait until then to see the diff.  The reason I'm
> not posting -04 now is because I'm still trying to work out an issue with
> Applicability Statement and with the port's name.
>
> Below are my detailed responses.
>
> Cheers,
> Kent
>
>
>
>
>
>
>
>> Typos
>> -----
>>
>
> I fixed all the issues you found.
>
>
>
>
>
>
>> Section 2.1, Page 3, Second Paragraph:  (wording)
>> -------------------------------------------------
>>
>> The second paragraph seems vague.  Would something along the lines of
>> the following text be clearer and/or more specific?
>
> I forwarded this comment to Steve Hanna, who wrote the Applicability
> Statement.  At first I was just going to ask if he was OK with the
> proposed text, but then I started thinking that I didn't agree with it.
> That is, I think that the SSH protocol does require mutual authentication
> and that NETCONF's requirement that it be possible to derive a "username"
> from the transport doesn't change that.  I'm still OK limiting Reverse SSH
> to just NETCONF, but I want the reason to be accurate.  I'm now waiting
> for a response from Steve on this.
>
>
>
>
>
>
>
>> Section 4, Page 4:  (wording)
>> -----------------------------
>>
>> The current text reads:
>>
>>    o  The NETCONF server initiates a TCP connection to the NETCONF
>>       client on the IANA-assigned Reverse SSH port YYYY.
>>
>>    o  The TCP connection is accepted and a TCP session is established.
>
>
> I'm not sure about this change since these bullet-points are preceded by
> the line "From the NETCONF server's perspective:".  The intent is to only
> explain the NETCONF-server's perspective, and to let the next section
> provide the client's perspective.   Currently, neither section references
> the remote peer, so that its text remains squarely focused on its side of
> the connection.  What do you think?
>
>
>
>
>
>
>
>> Section 5, Page 5, First Paragraph:  (wording)
>> ----------------------------------------------
>>
>> The current text reads:
>>
>>    "When the management system accepts a new incoming connection, it
>>     needs to authenticate the remote peer.  Ultimately, this entails
>>     identifying the peer and verifying its SSH host key.
>>
>>     Due to Reverse SSH having the network element initiate the TCP
>>     connection,"
>
>
> I changed the wording to be more clear, but did it another way, please let
> me know if you think it's OK!
>
>
>
>
>
>
>
>
>> Section 5, Page 6, First Paragraph:  (clarification)
>> ----------------------------------------------------
>>
>> The current text reads:
>>
>>    "However, configuring distinct host keys on the management system
>>    doesn't scale well, which is an important consideration to a network
>>    management system.  A more scalable strategy is to have the network
>>    element's host key signed by a common trusted key, such as a
>>    certificate authority.  Thus, the mangement system only needs to
>>    trust a single public key, which vouches for the authenticity of the
>>    various network element public keys."
>>
>> Please help me understand this.  The way this paragraph is written, it
>> is not clear to me why "signing each network element's host key with a
>> common trusted key" scales better than "configuring distinct host keys
>> on the management system".
>>
>> In either of these two situations, it seems like an administrator must
>> do work for each network element.  In one case, it is configuring host
>> keys, in another, it is signing each network element's host key.  If
>> anything, it seems like signing a host key for each network element
>> requires _more_ work for each network element, so it seems like this
>> would scale less well.
>>
>> What am I missing here?
>
>
> Very good question.  Of course it comes down to how the device's "entity
> certificates", as they are called, is distributed.  In the best case, as
> described in the zero-touch draft, the device would ship from factory with
> a built-in entity-certificate, signed by a trust-chain to its vendor's
> well-known trust anchor.  In this case, there is no additional effort
> needed, the management system only needs to trust the vendor's certificate
> for its well-known trust anchor.  For cases where the device doesn't ship
> from factory with an entity-certificate, introducing PKI is still
> advantageous as it decouples the management-system from direct
> involvement, such that it could be outsourced to some 3rd-party.  Makes
> sense?  What update would you like to see in the draft?
>
>
>
>
>
>
>
>
>> Section 7, Page 7, Third Paragraph:  (wording)
>> ----------------------------------------------
>>
>> In a few places in the third paragraph, and possibly in other places
>> in the document, would changing "needs to" to lowercase "must", or
>> lowercase "should", make the document a little more concise?  Example:
>>
>>    "Note that since the SSH server would have to be configured to know
>>     which IP address it needs to connect to,"
>>                         ^^^^^^^^
>
>
> I changed "needs to" to "is to" for this cited location and another I
> found.
>
>
>
>
>
> Thanks again,
> Kent
>
>
>
>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 4 Apr 2014 15:15:13 +0000

Hi Bert,

I just need to update the Change Log now.  Also, Stave Hanna hasn't
replied yet regarding the Applicability Statement.  I'll ping him again
while updating the Change Log.

I apologize for missing the date, but I was recently put on the steering
committee for a project and I had to spend time on it first.

Kent

---

From: t.petch <[email-masked]>
Date: Tue, 8 Apr 2014 14:44:59 +0100

I do not think that this is ready to advance.  I had not intended to
comment but having started on netconf-server, and found I had to read
5539bis to understand where it was going, I then found that reverse-ssh
was another piece of the jigsaw.

In particular, I think that this I-D is more or less updating RFC4742 in
its considerations of security.  And I think it may be confused about
public keys and certificates and their role in authentication.

Taken together, and I do not think they can be considered separately, I
do not think that the three I-Ds give a coherent view of how to secure a
NETCONF session.

I would point to the queries raised by Tadek and Bajpai which, to me on
the one hand seem spot on and on the other, seem to regard the subject
material of these three I-Ds as of a one - which I obviously agree with.

I think that netconf-server is the one in most need of progress and see
it as a Normative, not Informative, prerequisite.

Tom Petch

---

From: Kent Watsen <[email-masked]>
Date: Tue, 8 Apr 2014 16:24:01 +0000

Hi Tom,

Thank you for voicing my own thoughts as well.  I had previously raised
the idea of merging the reverse-ssh draft into a 4742bis, but the WG
agreed to keep it separate for simplicity sake.  That said, I like
symmetry, and it would be more consistent for 5539bis and a 4447bis,
rather than what we have now.  Just saying  ;)

Regarding Normative vs Informative, I recently asked about this and Bert
said that it comes down to if said draft needs to be understood and/or
implemented.  If this is the condition, then I believe it swings to being
Informative, as proprietary vendor-specific configuration could be used
alternatively.  As it is, the vendor can decide if they want to advertise
urn:ietf:params:xml:ns:yang:ietf-netconf-server-model in their <hello>
message.  Are you suggesting that advertising this capability in the
<hello> message should be required in order for an implementation to claim
they implement Reverse SSH for NETCONF Call Home?

Thanks,
Kent

---

From: t.petch <[email-masked]>
Date: Thu, 10 Apr 2014 12:28:55 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "t.petch" <[email-masked]>; "Bert Wijnen (IETF)"
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 08, 2014 5:24 PM

Hi Tom,

Regarding Normative vs Informative, I recently asked about this and Bert
said that it comes down to if said draft needs to be understood and/or
implemented.  If this is the condition, then I believe it swings to
being
Informative, as proprietary vendor-specific configuration could be used
alternatively.  As it is, the vendor can decide if they want to
advertise
urn:ietf:params:xml:ns:yang:ietf-netconf-server-model in their <hello>
message.  Are you suggesting that advertising this capability in the
<hello> message should be required in order for an implementation to
claim
they implement Reverse SSH for NETCONF Call Home?

<tp>

Kent,

There is a lot of inconsistency between reverse-ssh and 5539-bis and I
think the latter is the better model.

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.

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.

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.

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.

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.

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.

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.

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.

Tom Petch

Thanks,
Kent

On 4/8/14 9:44 AM, "t.petch" <[email-masked]> wrote:

>> > not posting -04 now is because I'm still trying to work out an
issue
>with
>> > the line "From the NETCONF server's perspective:".  The intent is
to
>only
>> >>    trust a single public key, which vouches for the authenticity
of
>the
>> >> Please help me understand this.  The way this paragraph is
written,
>it
>> > for its well-known trust anchor.  For cases where the device
doesn't
>ship

---

From: Kent Watsen <[email-masked]>
Date: Thu, 10 Apr 2014 21:55:19 +0000

Hi Tom,

>= 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.

>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).

>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...

>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?

>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

>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).

>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.

>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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Apr 2014 00:38:15 +0200

> drafts is to merge reverse-SSH into rfc4742  (i.e. rfc4742bis).

I tend to agree with Tom that 'reverse SSH' is potentially misleading
or that we should pick a consistent terminology for both the TLS and
the SSH transports. (I do not see that merging reverse SSH into RFC
4742 fixes the terminology split we have.)

And to make things a bit more confusing, we use 'inbound' and
'outbound' in the netconf server configuration data model. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 10 Apr 2014 23:08:53 +0000

Hi Juergen,

>4742 fixes the terminology split we have.)

What terminology change do you propose?  I can only think that adding the
word "reverse" into 5539-bis would be simpler than removing "reverse" from
the reverse-ssh draft...

>'outbound' in the netconf server configuration data model. ;-)

These are in feature statements only.  For instance:

  feature ssh {
       description
        "A server implements this feature if it supports NETCONF
         over Secure Shell (SSH).";
       reference
        "RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)";
     }

     feature inbound-ssh {
       description
        "The inbound-ssh feature indicates that the server can
         open a port to listen for incoming client connections.";
     }

     feature outbound-ssh {
       description
        "The outbound-ssh feature indicates that the server can
         connect to a client.";
       reference
        "RFC XXXX: Reverse SSH for NETCONF Call Home";
     }

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Apr 2014 09:04:57 +0200 (CEST)

> >I tend to agree with Tom that 'reverse SSH' is potentially misleading

+1

I think a phrase like "call home for SSH" describes it better.

> These are in feature statements only.

The terms should still be correct. "outbound-ssh" sounds like a normal
SSH client, but that is not the case here.

/martin

---

From: t.petch <[email-masked]>
Date: Fri, 11 Apr 2014 10:00:27 +0100

Snipping out the issues of terminology and security

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

London that Heartbeats were under-specified.  For SSH, heartbeats are
done
reconnection, or if it was disconnected due to a timeout - all that
state

* 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

---

From: t.petch <[email-masked]>
Date: Fri, 11 Apr 2014 10:04:56 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: "t.petch" <[email-masked]>; "Bert Wijnen (IETF)"
<[email-masked]>; <[email-masked]>
Sent: Friday, April 11, 2014 12:08 AM

Hi Juergen,

>4742 fixes the terminology split we have.)

What terminology change do you propose?  I can only think that adding
the
word "reverse" into 5539-bis would be simpler than removing "reverse"
from
the reverse-ssh draft...

  feature ssh {
       description

     feature inbound-ssh {
       description

     feature outbound-ssh {
       description

<tp>

Kent

I know, I was leaving that issue for the moment:-)

I think that parts of ssh-server have nothing to do with the server and
apply to the client as well, so that as long as you remember very
clearly that the document title is 'server' then inbound and outbound is
unambiguous (well, as long as you remember that it is the ssh server and
not the tcp server:-)

But as and when parts of ssh-server relate to the client, well then
inbound and outbound are less clear, so I think that the use of inbound
and outbound is an issue that needs more thought.

And inbound is quite widespread in ssh-server, appearing in sections
2.4, 2.5, 3.1, 3.2, 3.3, 3.4.  The usage is consistent within
ssh-server but at odds with what I see as a set of documents, 5539-bis,
reverse-ssh, ssh-server
(and, perhaps, system-mgmt).  I read them all before making any comments
and it is the inconsistency between them that is driving me now.

And, as I said before, I do see 5539-bis as the simplest, the clearest
and so the one to move reverse-ssh and ssh-server towards.

Which gives you the work to do, which is why I offered to help.

Tom Petch

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Fri, 11 Apr 2014 16:06:15 +0000

Hi Tom,

>and outbound is an issue that needs more thought.

How about "listen" and "call-home", mimicing the names used for the
configuration nodes?

>Which gives you the work to do, which is why I offered to help.

There looks to be WG consensus to do this now so, yes, please make this
change.  I suppose if we're removing "reverse" from the draft, then we
should rename it too - how about ietf-netconf-ssh-call-home?

Thanks,
Kent

---

From: t.petch <[email-masked]>
Date: Sat, 12 Apr 2014 13:20:44 +0100

Kent

I attach the updated XML.  I have replaced 'Reverse SSH' with 'call
home' or, where it seems necessary, 'NETCONF over SSH (call home),
following the style of 5539-bis.  xml2rfc says it is ok.  I update the
version to -05 and added a change log.  I think it would be wrong to
change the draft I-D name - yes, that name persists for ever in the data
tracker even after the RFC is created, but I think that the change of
name creates a discontinuity in the tracker that is a worse result.  I
think it would be better if you submitted this I-D - continuity again.

I would like to revise the first sentence of the Introduction/Abstract
(as I suggested last November) but including 'call home', but don't see
consensus on that yet so I have left that.

I will get back to you next week ( a busy one for me) on the other
points.

Tom Petch

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "t.petch" <[email-masked]>; "Juergen Schoenwaelder"
<[email-masked]>
Cc: "Bert Wijnen (IETF)" <[email-masked]>; <[email-masked]>
Sent: Friday, April 11, 2014 5:06 PM

Hi Tom,

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Apr 2014 19:27:05 +0000

>specific to a particular scenario.

Any NETCONF engine?  Are you suggesting an <are-you-alive/> RPC?

The peer that initiates a connection is the one that should provocatively
test the aliveness of the remote peer.   Normally, the northbound app
initiates the connection, and thus it should do it, but IETF don't have to
standardize anything for everything to work (so long as we use
SSH/TLS-level keep-alives). The only reason we're defining these things
now is so NETCONF server's can be generically configured.

Are you looking for a change in the text?

>what the I-D currently says, I can see that, but where do we want to end

The scope is for the NETCONF server to be configurable - both TLS/SSH and
both listen/call-home.

>this one) v 'I am closing pro tem but expect to return when I have

I'm not a fan of putting semantics into the <close-session> method.  And
in the call-home case, since it's the NETCONF server that would timeout,
it can't send an RPC to the NETCONF client anyways, it simply closes the
underlying transport.

Kent

---

From: t.petch <[email-masked]>
Date: Sat, 19 Apr 2014 16:02:58 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "t.petch" <[email-masked]>; "Bert Wijnen (IETF)"
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 14, 2014 8:27 PM

The peer that initiates a connection is the one that should
provocatively
test the aliveness of the remote peer.   Normally, the northbound app
initiates the connection, and thus it should do it, but IETF don't have
to
standardize anything for everything to work (so long as we use
SSH/TLS-level keep-alives). The only reason we're defining these things
now is so NETCONF server's can be generically configured.

<tp>
Kent

The heartbeat protocols that I know are symmetric, even when there is,
at
some protocol level, a client and server.  Sometimes the one protocol so
that either end can detect a loss of connectivity, sometimes two
protocols, one for each end, perhaps with different properties to suit
the different ends.

And when you say 'initiates the connection', which connection:-)  The
TCP one or the NETCONF one?

You say, in netconf-server,
" This connection type minimizes any
  application-to-server data-transfer delay,
  albeit at the expense of holding resources
  longer.";

which I see by way of justification, but I see the argument as being
equally valid for both ends.  TCP famously can be down for hours with
noone noticing as some developers of syslog found to their surprise.  Is
it more important for the device generating a syslog messge to know that
the transport is up and running, or that the receiver of the messages
knows that a transport failure has not stopped them coming through?

I would like to see more justification of why this hearbeat should be
asymmetric, suspecting that down the tracks we will wish it were
otherwise

This then drives the mechanics but at a protocol level, I would hope we
would be re-using the existing SSH/TLS facilities, keeping them the same
in-so-far as we can.

Tom Petch

>what the I-D currently says, I can see that, but where do we want to
end

The scope is for the NETCONF server to be configurable - both TLS/SSH
and
both listen/call-home.

Kent