RE: [saag] draft-kwatsen-reverse-ssh submission for review

[Kent Watsen <kwatsen%juniper.net@localhost>]

> Understood; I was asking because it sounded like Juniper was using 
> a port they hadn't registered ;-( That should be fixed...

Indeed, and that is exactly what we're trying to do with this submission.  Our previous attempt to have IANA assign a port for this ended with their recommendation to bring it to IETF for standardization.  It's taken awhile, but here we are.



> Netconf over ssh uses a different port, as noted above.

The need for the port 830 assignment was only to facilitate filtering.  As RFC 4742 says:

   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.

I suppose IETF may feel a similar need to facilitate filtering on a per SSH-based service, but I wouldn't recommend this as port-based filtering is no longer practical (e.g. consider the number of HTTP-based protocols).  Application-based firewalls with deep-inspection capability are needed these days.  In either case, to the original question, there isn’t a *need* for more than one IANA assigned port, since SSH already has a mechanism built into it for the client to select which protocol/subsystem to run on a channel.



> What's the reason for not solving this by having the client just listen 
> on the SSH server port?

Because then it would be expected to be the SSH server.  As discussed in the Introduction, a goal of this draft is to ensure the device is always the SSH server and the application is always the SSH client.  We don't want to disturb which peer is which as far as the SSH Transport, Authentication, and Connection protocols are concerned.


Thanks,
Kent