Subject: Re: [Isms] user@address:port proposal for secshell

From: Wes Hardaker <[email-masked]>
Date: Mon, 25 Aug 2008 14:54:44 -0700

>>>>> On Mon, 25 Aug 2008 17:48:38 -0400, Jeffrey Hutzelman <[email-masked]> said:

JH> "Represents either a hostname or IP address, along with a port
JH> number and an optional username".

that's fine with me.

JH> "Represents either a hostname or IP address, along with an
JH> optional port number and/or username".

The port number isn't optional, so that doesn't work.

JH> The latter, of course, implies a change to make the ":port" part be
JH> optional.  I don't recall whether we've already discussed this, but
JH> I'm not sure I see a need to require specification of a port.

Most of the current SNMP transport specifications include a port number
so I suspect that's the reason for ensuring it's always there (then
again, though, most transport address specs are binary encoded not ascii
text).

I thought about bringing up whether it should be optional or not, but
never had a good reason why it would be beneficial to be optional...

Personally, I don't care too much.  The only question comes when two
different implementations use two different default values for port
numbers.

>> * I THINK the sshtmLCDTable object can be removed after completion
>> of this since the mapping is no longer needed.

JH> Perhaps.  I suspect you'll end up wanting some way to provide actual
JH> credentials to be used, such as a public/private key pair, but it's
JH> possible the mechanism for managing that can be
JH> implementation-dependent.

Well, last time I suggested that a zillion people screamed that's out of
scope of the WG and that the best that could be done would be a lookup
key/string for now ;-)
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 25 Aug 2008 18:02:23 -0400

> never had a good reason why it would be beneficial to be optional...

Well, there is a default port for SSH.
Presumably there will be a standard port for SNMP-over-SSH, though it's 
unclear to me whether it should be the same as the default port for SSH or 
something different.

It seems counterproductive for users to have to know that SSH uses port 22.

> different implementations use two different default values for port

Well, I think we'd have to standardize the default port if we did this.

> scope of the WG and that the best that could be done would be a lookup

Well, that's probably true.  I was probably even one of those people. :-)

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 25 Aug 2008 17:48:38 -0400

--On Monday, August 25, 2008 02:11:57 PM -0700 Wes Hardaker 
<[email-masked]> wrote:

>
> We discussed this in the meeting and it's unclear that consensus on it
> has been reached, but I wanted to spell out the details of what would
> need to be changed if we support what I outlined in:
>
>      From: me
>   Subject: [Isms] Proposed SSH Transport Address Changes (and a quick nit)
>      Date: Thu, 03 Jul 2008 09:43:05 -0700
>
> Specifically, if you'll recall, I was proposing allowing for these since
> SSH users are familiar with the syntax, and as Pasi pointed out in the
> meeting we can name both sides of the connection in an
> bidirectional/asymmetric authentication protocol:
>
>   [email-masked]:161
>   [email-masked]:161
>   wes@[::1]:161

I support this proposal.  In fact, as discussed at the meeting, I think it 
is essential because we must be able to specify the username to be 
presented to the remote ssh server, and in the case of a notification 
originator this is practically guaranteed not to be related to the 
securityName in any meaningful way.

> * Section 7 in the MIB Module
>
>   - The SnmpSSHAddress should be modified to allow for the new leading
>     prefix.  Suggest a rewrite of the beginning text to the following
>     (adding bits and pieces to make it work):
>
>          "Represents either a hostname with a port number, an IP
>          address with a port number, a username, hostname and port
>          number or a username, IP address and port number.

Ugh ugh ugh.  How about...

   "Represents either a hostname or IP address, along with a port
    number and an optional username".

Or even

   "Represents either a hostname or IP address, along with an
    optional port number and/or username".

The latter, of course, implies a change to make the ":port" part be 
optional.  I don't recall whether we've already discussed this, but I'm not 
sure I see a need to require specification of a port.

>   of this since the mapping is no longer needed.

Perhaps.  I suspect you'll end up wanting some way to provide actual 
credentials to be used, such as a public/private key pair, but it's 
possible the mechanism for managing that can be implementation-dependent.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 25 Aug 2008 15:18:44 -0700

>>>>> On Mon, 25 Aug 2008 18:02:23 -0400, Jeffrey Hutzelman <[email-masked]> said:

JH> It seems counterproductive for users to have to know that SSH uses
JH> port 22.

The current transport address definitions for UDP/TCP, for example,
require a port spec.  I suspect many users don't actually know, however,
that it's port 161 for commands and 162 for notifications because most
things hide that from the users.

JH> Well, I think we'd have to standardize the default port if we did this.

Currently we have two different ports for SNMP, as just mentioned.
Frequently notifications are sent to a different application than an
agent running on the device (for obvious reasons).  Thus we need to
some combination of:

1) say all address specs must include a port
2) specify default port destinations for both notifications and commands
3) specify default ssh subsystem names for both notifications and commands
   (right now, there is just "snmp" which is entirely possible not the
   best solution for trying to connect to a management station that has
   it's own agent running on it in addition to the notification receiver).

>> scope of the WG and that the best that could be done would be a lookup

JH> Well, that's probably true.  I was probably even one of those
JH> people. :-)

You were.  But I wasn't going to bring it up ;-)
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms