Subject: Re: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 May 2007 15:03:48 -0400

On Friday, April 27, 2007 06:19:29 PM +0200 "tom.petch" 
<[email-masked]> wrote:

> Understand that an implementation can use any port it is configured with
> as long as its peer agrees.
>
> But I think that the text in tmsm 3.1.1 needs amplfying, ie where it says
>
> "  To differentiate a session established for different purposes, such
>    as a notification session versus a request-response session, an
>    application can use different securityNames or transport addresses
>    (e.g., port 161 vs. port 162)."
> add something like
> "Note that some transport models may be allocated a single well-known
> port for all sessions."

I don't see the issue here.  The number of well-known ports allocated for a 
given transport model doesn't affect which or how many ports an application 
can use.  OTOH, I don't object to the new language in -08, either, except 
for the bit about distinguishing between "SNMP traffic" and 
"notifications".  As far as I understand, notifications _are_ SNMP traffic.

> (assuming we do not ask for two ports for SSH).  I appreciate that the
> consensus on the list was reuse or not reuse was not an issue but I worry
> that we have this one wrong so want the documents to make this clear for
> any other reviewers.

FWIW, I don't think we do have this one wrong.  While message processing in 
the SNMP application might be substantially different for notifications vs 
RR, the processing for TSM, the SSH transport model, and SSH itself will 
all be substantially the same.  It would seem to make much more sense to 
use different securitynames and/or subsystem ID's.

In fact, I wonder if we shouldn't change SnmpSSHAddress to allow an 
optional [:subsystem-name] after the port number, with the "snmp" subsystem 
being used when none is given.  This would allow multiplexing of different 
types of traffic and/or different SNMP engines on the same ssh port.

> And, while suggesting revisions to tmsm, I wonder if the reference to
> RFC4366 should be to RFC4346 throughout.  As far as I know, we are not
> using any TLS extensions.

Well, we're not using TLS at all, but you're right; the reference should be 
to the base spec.

-- Jeff

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Fri, 18 May 2007 15:58:18 -0400

Hi, 

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Friday, May 18, 2007 3:04 PM
> To: tom.petch; David Harrington
> Cc: [email-masked]; Jeffrey Hutzelman
> Subject: Re: TMSM and Port was Re: [Isms] Question regarding 
> SNMPv3engine-iddiscovery process
> 
> 
> 

Changed to "SNMP request-response traffic"

> types of traffic and/or different SNMP engines on the same ssh port.

Does SSH know how to process that optional field after the port#?
Or is this an extension only to the SSH transport model?
What should the SSH Transport Model inside an SNMP engine do if
presented with [:netconf] or [:X11] or whatever?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 May 2007 16:12:13 -0400

> Or is this an extension only to the SSH transport model?

No; this would be an extension to the transport model, indicating that SSH 
should be asked to invoke some other subsystem instead of "snmp".  Note 
that SSH doesn't know anything about this "host:port" thing, either, though 
there are certainly some SSH _implementations_ that accept a parameter 
written that way.

> presented with [:netconf] or [:X11] or whatever?

Well, the [] were really just to indicate it's optional; they're not part 
of the syntax.  If presented with a transport address like 
some.host.com:22:netconf, the SSH transport model should open an ssh 
connection to port 22 on some.host.com, and ask SSH to invoke the "netconf" 
subsystem.  What happens after that won't be pretty, because the other end 
isn't speaking SNMP, but it also won't be any worse than if you used some 
other transport model with the wrong port.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Fri, 18 May 2007 16:54:38 -0400

I'm afraid I don't see the benefit of this extension. Can you
enlighten me?

dbh

> Sent: Friday, May 18, 2007 4:12 PM
> To: David Harrington; 'tom.petch'
> Subject: RE: TMSM and Port was Re: [Isms] Question regarding

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 May 2007 17:33:21 -0400

> I'm afraid I don't see the benefit of this extension. Can you

The idea is to allow multiplexing of traffic by SSH subsystem name, rather 
than by TCP port number.  I thought this might be interesting to the people 
who were concerned about only having one default port.  Let's see if anyone 
else thinks this would be useful; if not, we can just drop it.

---

From: "tom.petch" <[email-masked]>
Date: Sat, 19 May 2007 20:45:43 +0200

I am one of those who has been concerned about telling traffic apart.  I see it
at present with NATs, where I do see different treatment for ports 161 and 162
and can envisage it for a secure transport where users may wish to give
different levels of security for different types of traffic.

Different subsystems would give part of this.

So if TMSM takes this away, then I would like this to be clearly spelt out so
others are aware and can comment.  SNMP, for me, has a habit of burying bad news
in some obscure combination of paragraphs whose impact is not apparent until too
late:-{

Tom Petch

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "David Harrington" <[email-masked]>; "'tom.petch'"
<[email-masked]>
Cc: <[email-masked]>; "Jeffrey Hutzelman" <[email-masked]>
Sent: Friday, May 18, 2007 11:33 PM
Subject: RE: TMSM and Port was Re: [Isms] Question regarding
SNMPv3engine-iddiscovery process

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 21 May 2007 19:25:38 -0400

On Saturday, May 19, 2007 08:45:43 PM +0200 "tom.petch" 
<[email-masked]> wrote:

> I am one of those who has been concerned about telling traffic apart.  I
> see it at present with NATs, where I do see different treatment for ports
> 161 and 162 and can envisage it for a secure transport where users may
> wish to give different levels of security for different types of traffic.
>

Yes, but note that subsystem requests happen inside the authenticated, 
encrypted SSH connection, and so cannot be inspected by NAT's, firewalls, 
etc.  They also happen too late to allow choice of subsystem to influence 
things like ports.  If you have an ISMS deployment where you want to 
require stronger ciphers for certain types of requests, then running a 
separate SSH server on a different port is still your best bet.

> So if TMSM takes this away, then I would like this to be clearly spelt
> out so others are aware and can comment.  SNMP, for me, has a habit of
> burying bad news in some obscure combination of paragraphs whose impact
> is not apparent until too late:-{

I don't see anything in TSM, TMSM (ugh this needs a new name), or the SSH 
transport mapping which would eliminate the ability to use arbitrary ports.

-- Jeff