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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf