Hi Sam,
Hi. This is not a blocking comment nor am I even asking for a change;
I'm just asking people consider this for netconf and future work.
Netconf currently recommends that netconf over ssh be run over a
different port than the normal ssh port.
That seems like a fine idea. I think there are cases where you might
want to allow access to netconf but not allow access to the CLI
through the normal ssh port.
However I think in many cases it would not be a security problem if
the netconf subsystem were available over the normal ssh port. In
many applications the same privileges will be granted to users over
the CLI as to the same users over netconf. In many cases the
functionality available through netconf will also be available through
the CLI.
Obviously what you're suggesting isn't hard to do, and I agree with you
that in many cases use of port 22 would be safe (and it would certainly
be true for the VAST majority of cases when connecting to network
infrastructure). However, once we decide to cover the other cases where
we are trying to give firewall administrators some leeway, I'm not sure
there's an added advantage to adding text along the lines of "well,
sometimes you can use port 22." For one it makes the tool building
HARDER if the other port isn't LISTENED to as well, because your canned
tools would end up playing guessing games or requiring extra
configuration. And for our purposes I think I know of one SSH
implementation on a general computing device that hardcodes the port to
22 and that implementation also doesn't have means to support additional
applications.
All of this having been said, I am beginning to grow concerned about
port assignments and firewall administration. If you're a firewall
administrator the IETF is about to make your life and perhaps the
performance of some low end / old gear, slightly more complex. With
netconf there will be either two or three new ports to block. ISMS will
later add another port. And these are just the protocols I've been
playing with, as of late. I'm sure a bunch of other protocols are out
there that I don't know about. In addition there is the comparably
minor matter of well known port assignments.
All I'm saying now is that it is probably worth some thought to
reconsider the substrate RFC to give additional guidance for protocols
that have a notably similar purpose.
Regards,
Eliot
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf