Subject: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt

From: [email-masked]
Date: Tue, 29 Oct 2013 13:14:31 -0700

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.

    Title         : Reverse Secure Shell (Reverse SSH)
    Author(s)     : K. Watsen
    Filename      : draft-ietf-netconf-reverse-ssh
    Pages         : 15 
    Date          : Oct. 29, 2013 
    
 This memo presents a technique for a NETCONF server to initiate a SSH
   connection to a NETCONF client.  This is accomplished by the NETCONF
   client listening on IANA-assigned TCP port YYYY and starting the SSH
   client protocol immediately after accepting a TCP connection on it.
   This role-reversal is necessary as the NETCONF server must also be
   the SSH Server, in order for the NETCONF client to open the IANA-
   assigned SSH subsystem &quot;netconf&quot;.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-reverse-ssh-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Oct 2013 13:30:04 -0700

Hi, Kent, et al.:

As we discussed several years ago, why is this still requesting a new 
port vs. reusing #22?ssh

At the very least, there needs to be a thorough discussion of that issue 
in this doc, and it appears to be missing. I considered this issue in 
2009, and still feel that there is insufficient justification for a 
separate assignment for this service.

Additionally, this doc uses 7022 as the configuration example; that is 
inappropriate, esp. because 7022 is currently assigned to another 
service. unassigned numbers should never be used as examples.

Joe

On 10/29/2013 1:14 PM, [email-masked] wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 30 Oct 2013 19:48:26 +0000

>As we discussed several years ago, why is this still requesting a new

To reuse port 22 would require changing RFC 4253 (the SSH Transport
protocol), to add some reversal flag into the SSH handshake.  While
technically possible, it would be inconsistent with the newly added
Applicability Statement (added by folks from the Security Area) limiting
the ability to reverse SSH to just NETCONF servers (i.e. it's not a
universal solution).

BTW, the rfc5539bis draft is also asking IANA for a new port-assignment
for call-home using TLS and it also has a similar Applicability Statement
recently added to it...

>separate assignment for this service.

Add a section for why we want a port-assignment?  - can that be something
that's worked out on a mailing list (such as we're doing right now) and
the draft just implements the agreed upon solution?

>service. unassigned numbers should never be used as examples.

Sure, I'll remove the <port> element from the example - it's defined in
the YANG module to be optional field anyway, so not having one specified
is still valid...

Thanks,
Kent

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Oct 2013 15:53:38 -0700

Hi, Kent,

On 10/30/2013 12:48 PM, Kent Watsen wrote:
> protocol), to add some reversal flag into the SSH handshake.

Of course, but that's effectively what you're doing except you're 
obscuring it by using a separate port.

> While

Sure, then it would then use port 830 rather than 22, but that's still a 
good argument for using port 830 in that case.

> for call-home using TLS and it also has a similar Applicability Statement

And for similar reasons I would suggest they use the existing NETCONF 
TLS port.

> the draft just implements the agreed upon solution?

Not just why you want a port assignment; why this isn't an extension of 
the existing NETCCONF SSH service.

> the YANG module to be optional field anyway, so not having one specified

Thanks. It's always useful to avoid using examples until they're assigned.

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Oct 2013 07:51:53 +0100

On Wed, Oct 30, 2013 at 03:53:38PM -0700, Joe Touch wrote:
> 
> And for similar reasons I would suggest they use the existing
> NETCONF TLS port.
> 

Joe,

if you have a box that runs a regular NETCONF server and a NETCONF
client that is used for call-home by other remote NETCONF servers, 
how are they going to share the port number?

/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: Joe Touch <[email-masked]>
Date: Thu, 31 Oct 2013 09:51:48 -0700

> how are they going to share the port number?

The question isn't whether this makes implementation simpler, it's 
whether this defines a new service.

This situation above isn't addressed at all in the "applicability 
statement" of the doc.

Finally, there are a lot of ways in which a single port can be shared by 
multiple processes, so that's an implementation detail that doesn't 
necessarily justify a new port. E.g., if the two are expected to be 
implemented in a single software system (which would be the case if 
there is expected shared or coordinated state, etc.), then they would 
share a port very easily.

So far, I still have not heard a description of a new service, but 
rather an extension of an existing one.

Joe

---

From: Andy Bierman <[email-masked]>
Date: Thu, 31 Oct 2013 10:32:53 -0700

Hi,

I think a new port number is needed or else an important use-case
cannot be implemented.

We want to be able to support a mid-level manager that implements
network-wide data models.  An NMS uses NETCONF to manage the
network models (MLM in plain NETCONF server role).  The MLM
manages lots of individual devices with NETCONF, using NETCONF
over Reverse SSH (MLM in NETCONF client role).

The service may be NETCONF, but NETCONF defines a client peer and a server
peer,
and they are very different.  If the same port is used, then the service
deamon
does not know which role is being requested.

Andy

On Thu, Oct 31, 2013 at 9:51 AM, Joe Touch <[email-masked]> wrote:

> The question isn't whether this makes implementation simpler, it's whether
> this defines a new service.
>
> implemented in a single software system (which would be the case if there
> is expected shared or coordinated state, etc.), then they would share a
> port very easily.
>
> So far, I still have not heard a description of a new service, but rather
> an extension of an existing one.
>
> Joe
>
> ______________________________**_________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/netconf<https://www.ietf.org/mailman/listinfo/netconf>
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Oct 2013 10:46:02 -0700

On 10/31/2013 10:32 AM, Andy Bierman wrote:
> The service may be NETCONF, but NETCONF defines a client peer and a
> server peer, and they are very different. If the same port is used,
> then the service deamon does not know which role is being requested.

Why would (should) that not happen in-band, as part of the message type?

Joe

---

From: Kent Watsen <[email-masked]>
Date: Thu, 31 Oct 2013 18:06:30 +0000

>Why would (should) that not happen in-band, as part of the message type?

Because it would require updating both the SSH and TLS protocols to enable
reversal before the crypto tunnel is setup.  This is not likely to garner
consensus given the Applicability Statements limiting the solution to just
NETCONF, especially given the option to use a port instead.

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 31 Oct 2013 19:14:46 +0100 (CET)

> NETCONF, especially given the option to use a port instead.

Agreed.  Also, I think these are fundamentally two different services;
one is a NETCONF server (e.g. some managed device) and the other a
NETCONF client (e.g. a NMS).

/martin

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Oct 2013 11:17:40 -0700

> NETCONF client (e.g. a NMS).

First, can any of that be explained in this doc?

In specific:

	- how the services differ

	- why reversing the existing netconf-ssh system
	isn't a useful way forward

	- the specific use case where both a client and server
	would sit on the same device, and why those would be independent

All of these questions are begged by the name "reverse NETCONF". If 
that's not what you're really doing, this needs a better, more accurate 
description.

Joe