Subject: [Netconf] rfc 6242 (rfc 4742) ssh port requirement confusing in practice?

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Sep 2012 17:37:03 +0200

Hi,

while doing interop testing before the interop, we did discover this
wording in RFC 6242 (unchanged from RFC 4742):

   In order to allow NETCONF traffic to be easily identified and
   filtered by firewalls and other network devices, NETCONF servers MUST
   default to providing access to the "netconf" SSH subsystem only when
   the SSH session is established using the IANA-assigned TCP port 830.
   Servers SHOULD be configurable to allow access to the netconf SSH
   subsystem over other ports.

Looking at implementations running as subsystems of openssh, it seems
some are liberal by default (it does not matter which port you used to
connect to the ssh daemon) whilef others try to verify that the port
number used to connect is 830. Checking the port number is likely more
closely following the text above.  However, it seems the MUST really
comes down to how the netconf system is deployed and configured, that
is a careful implementation being fully compliant to the text may be
shipped in a way such that is not fully compliant to the "default only
port 830" text. In other words, the MUST is not an implementation
requirement per se but more of a requirement how the netconf system
has to be configured when the software is shipped.

<soap>
  It seems the control of which SSH subsystem can be invoked over
  which port number should really reside in openssh, but I think this
  is not really configurable there. Some NETCONF subsystems seem to
  try to figure out which port number was used and then they may drop
  the session while other subsystems do not seem to care.
</soap>

Why do I write all this? Well, we installed one NETCONF package and
after installation it did allow NETCONF only over port 830 (port 22
sessions were closed before the hello message). A second NETCONF
package did after installation do NETCONF only over port 22 (since the
installation apparently did not reconfigure/restart the SSH daemon to
listen on port 830). For a normal user, this is a rather confusing
experience since at the end one had to provide different port numbers
to talk to both installations. (Things got more complicated because
the log message produced by the NETCONF subsystem of the first package
was just telling us "access denied" and not something like "access
denied on port 22", which would have given us a better clue where the
problem really is.)

/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: Phil Shafer <[email-masked]>
Date: Wed, 26 Sep 2012 14:53:00 -0400

>  the session while other subsystems do not seem to care.

Yup, the server should be counting on the lower layers to get the
port access right.

What we meant in the referenced section of the RFC is that turning
on "netconf" as a service should default to port 830, but the user
should be able to config it to use an alternate port (e.g. 18300).
This is independent of using openssh.

For example, in JUNOS, the configuration:

    [system services]
    netconf {
        ssh;
    }

(where "ssh" is a presence container) makes an inetd.conf file like:

netconf stream tcp nowait/75/150 root /usr/sbin/sshd sshd -i -f /var/etc/sshd_conf -o SubsystemOnly=netconf -o Protocol=2
netconf stream tcp6 nowait/75/150 root /usr/sbin/sshd sshd -i -f /var/etc/sshd_conf -o SubsystemOnly=netconf -o Protocol=2

but you can change the port using:

    [system services]
    netconf {
        ssh {
            port 18300;
        }
    }

To make:

18300 stream tcp nowait/75/150 root /usr/sbin/sshd sshd -i -f /var/etc/sshd_conf -o SubsystemOnly=netconf -o Protocol=2
18300 stream tcp6 nowait/75/150 root /usr/sbin/sshd sshd -i -f /var/etc/sshd_conf -o SubsystemOnly=netconf -o Protocol=2

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Sep 2012 12:48:55 -0700

> denied on port 22", which would have given us a better clue where the

Not that I might have something to do with one of these A or B packages...

There is some old code in Yuma to work-around an OpenSSH bug on MACOSX.
I just checked OpenSSH 5.6p1 and it is fixed now.  I will take the code out
of yuma that allows port 22 on a MAC by default.

> /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Sep 2012 21:56:25 +0200

> 18300 stream tcp6 nowait/75/150 root /usr/sbin/sshd sshd -i -f /var/etc/sshd_conf -o SubsystemOnly=netconf -o Protocol=2

I think I understand the intention of the text in the RFC but with the
two packages we installed today, our experience was lets say somewhat
surprising. We now try the port 830 first, if the connection attempt
fails we try port 22 as a backup.

The way you seem to hook things into inetd seems more sensible than
just hooking the subsystem into the standard sshd itself. Is the
SubsystemOnly option a standard sshd option or a Junos specific
extension? I did not see it in the openssh sources...

/js

---

From: Phil Shafer <[email-masked]>
Date: Wed, 26 Sep 2012 16:25:30 -0400

>extension? I did not see it in the openssh sources...

Doh!!  Sorry, yes it's an JUNOS extension.  Should have checked.
I can likely provide a patch if anyone wants it.

Thanks,
 Phil

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Sep 2012 22:34:57 +0200

>   subsystem over other ports.

I hope you guys are talking about the DESTINATION port here, not the  
SOURCE port.
(This is not entirely clear from the text; you might want to fix this  
in the process of clarifying it.)

Gruesse, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Sep 2012 08:15:26 +0200

On Wed, Sep 26, 2012 at 10:34:57PM +0200, Carsten Bormann wrote:
> (This is not entirely clear from the text; you might want to fix
> this in the process of clarifying it.)

If you feel strongly, please post an erratum.

/js