Subject: [Isms] snmp: URI scheme transport extensions

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2009 09:29:24 +0200

Hi,

while doing some SNMP during vacation, I did run into an issue with
the snmp: URI scheme defined in RFC 4088. When RFC 4088 was created,
we excluded transport information from SNMP service URIs. Now, with
the presence of much more transports, it would be really nice to have
the URI format supporting transport parameters, e.g.

     snmp://[email-masked]:5161;transport=ssh
                                    ^^^^^^^^^^^^^^
                                         new

I would be willing to work on this because I need it for some tools;
perhaps this work should be hosted at OPSAWG? I obviously forgot to
bring this up while ISMS was rechartering. But the transports we have
to provision extend ISMS transports anyway so OPSAWG might be a good
choice. Anyway, at this point in time, I just bring this up to see
whether there is interest to work this out or it is just me.

/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: Wes Hardaker <[email-masked]>
Date: Mon, 27 Jul 2009 01:12:46 -0700

>>>>> On Mon, 27 Jul 2009 09:29:24 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> snmp://[email-masked]:5161;transport=ssh
JS>                                 ^^^^^^^^^^^^^^
JS>                                 new

I think you're still missing an important element, namely the
securityModel.  No where above does it specify TSM anywhere so I don't
think it's complete as is.

[I think that's likely missing from 4088 as well, for that matter,
regardless of whether it's updated for transport specific concerns; the
fact that it's excluded from the original document is sort of odd in my
opinion in the first place since we're obviously to the point where
multiple security models exist (although they've existed long before this)]

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "David Harrington" <[email-masked]>
Date: Mon, 27 Jul 2009 10:47:36 +0200

Hi,

I don't use URIs in my work, so I may be overlooking why we need this.

Why do we need to specify the transport in the URI? We are already
specifying port 5161, which is snmp/ssh.

Why do we need to specify the securityModel in the URI? It is already
specified in the SNMP header.

If the purpose is to specify to the URI user which transport should be
used, and which secmodel should be used, then the information is
incomplete. Wouldn't we need to specify the securityName,
securityLevel, and so on as well? and maybe the ssh username to use?
In fact, wouldn't we need to specify everything that could be
specified in the set of tables in the notification-mib?

What is the use case that requires including this info in the URI?

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Wes Hardaker
> Sent: Monday, July 27, 2009 10:13 AM
> To: [email-masked]
> Subject: Re: [Isms] Ismssnmp: URI scheme transport extensions
> 
> >>>>> On Mon, 27 Jul 2009 09:29:24 +0200, Juergen 
> Schoenwaelder <[email-masked]> said:
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 27 Jul 2009 02:12:52 -0700

>>>>> On Mon, 27 Jul 2009 10:47:36 +0200, "David Harrington" <[email-masked]> said:

DH> Why do we need to specify the transport in the URI? We are already
DH> specifying port 5161, which is snmp/ssh.

You're presuming TCP there.  You're also presuming a standard port is
being used and you can determine from that what is running on it, which
isn't a safe assumption.

DH> Why do we need to specify the securityModel in the URI? It is already
DH> specified in the SNMP header.

It's configuring a client.  Consider a URI the equivalent of a
TARGET-MIB entry that specifies how the client should connect.

The point of the URI stuff (I don't use it either, but Juergen will
correct me if I'm wrong) is to be able to do the equivalent of:

  snmpget snmp://[email-masked]:5161;transport=ssh sysContact.0

No other command line options needed because it's all in the URI string.

[on a side note, I *did* write a plugin to KDE once to make their web
browser do something almost exactly like this...  Connect via SNMP to a
remote agent given a URI and display the results.]

DH> In fact, wouldn't we need to specify everything that could be
DH> specified in the set of tables in the notification-mib?

I think so, yes [but really it's a target].

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2009 11:32:04 +0200

> think it's complete as is.

Yes, I agree. I was thinking about having a default for all this as we
do now - you get SNMPv3/USM/UDP. If you specify transport=ssh, you get
securitymodel=tsm as default - I did not spell this out.
 
> regardless of whether it's updated for transport specific concerns;
> the fact that it's excluded from the original document is sort of
> odd in my opinion in the first place since we're obviously to the
> point where multiple security models exist (although they've existed
> long before this)]

When RFC 4088 was done, we scoped the work and now might be the time
to make it more complete. What we discussed back then was more version
information for community based SNMP, e.g.

snmp://[email-masked]:5161;version=snmpv1

(but we felt that opening this can of worms for a historic protocol
version could be troublesome and so we tossed this idea).

/js

---

From: "David Harrington" <[email-masked]>
Date: Mon, 27 Jul 2009 11:39:35 +0200

Hi,

Since the purpose of ISMS is to add new transports, I would think this
would belong in ISMS.

dbh 

> Behalf Of Juergen Schoenwaelder
> Sent: Monday, July 27, 2009 9:29 AM
> To: [email-masked]
> Subject: [Isms] snmp: URI scheme transport extensions
> 
> Hi,
>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 27 Jul 2009 12:25:48 +0200

Hi,

I believe having ssh **imply** tsm is inappropriate from an RFC3411
modularity POV.

dbh

> Sent: Monday, July 27, 2009 11:32 AM
> To: Wes Hardaker
> Cc: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2009 12:33:39 +0200

> What is the use case that requires including this info in the URI?

We have no interoperable way to write down and to pass around how you
access SNMP resources. The snmp: service URI format does address this
but the definition is incomplete.

I have a command line tool that uses snmp: URIs instead of collections
of command line options to specify to which agent you talk to - and it
also generates such URIs if you want to. Having a compact serialized
notation to pass around this information is helpful. RFC 4088 was
actually created because some MIB modules had a need to indicate in a
compact way (= one MIB object) where a management application can be
found without having to go through multiple related MIB tables.

Cut'n'paste of URIs really works great compared to cut'n'paste of
collections of MIB objects. ;-)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2009 12:35:29 +0200

> I believe having ssh **imply** tsm is inappropriate from an RFC3411

But not incorrect. ;-) There is only an issue if TSM gets replaced by
something else and the outcome in that case just won't be as short.

/js

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 27 Jul 2009 18:03:32 -0400

> being used and you can determine from that what is running on it, which

Right.  There are any number of reasons why I might want to run this on a 
non-standard port, or run something else -- even something SNMP related -- 
on port 5161.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 27 Jul 2009 18:08:47 -0400

--On Monday, July 27, 2009 11:32:04 AM +0200 Juergen Schoenwaelder 
<[email-masked]> wrote:

>> >>>>> On Mon, 27 Jul 2009 09:29:24 +0200, Juergen Schoenwaelder
>> >>>>> <[email-masked]> said:
>>

I still don't think transport= is the right approach.  In your URL example, 
is 'tester' intended to be a securityName or part of the SSH transport 
address?  I suspect the answer is that for UDP/USM it is a securityName, 
but for TCP/SSM/TSM it is part of the SSH transport address, indicating the 
SSH username to use.  That is, the syntax depends on the transport being 
used.

The right way to have differing syntax is to use different URI schemes. 
UDP, TCP, SSH, TLS, DTLS/UDP, and DTLS/SCTP should probably all have 
different URI schemes.

Once you've done that, different schemes can imply different defaults, so 
the default security model for SSH, TLS, DTLS/UDP, and DtLS/SCTP is TSM, 
while the default security model for UDP and TCP is USM.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 28 Jul 2009 00:56:25 +0200

> SSH username to use.  That is, the syntax depends on the transport being 

In USM, you specify a user name - since in both cases (USM and SSH)
the default transform is an identity transform, the difference between
a user name and a securityName is subtle.

> while the default security model for UDP and TCP is USM.

I note this is legal:

   sip:alice:[email-masked];transport=tcp

They obviously do not have a siptcp: scheme - but they do have sips:
(while they deprecated the sip:<bla>;transport=tls version but then I
note that sips actually implies TLS over the complete E2E path and not
just one hop).

I guess we need advice from URI experts. There was probably a good
reason why we ignored all this when we did RFC 4088...

/js