Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process

From: "tom.petch" <[email-masked]>
Date: Thu, 5 Apr 2007 18:12:51 +0200

> -----Original Message-----
> From: Tammy Alper [mailto:[email-masked]]
> Sent: maandag 19 maart 2007 9:41
> To: [email-masked]
> Subject: [Isms] Question regarding SNMPv3 engine-id discovery process
>
> Hello,
>
> I have a question regarding the SNMPv3 engine-id discovery process:
> Suppose an SNMP engine wants to discover a remote engine-id value,
> for the purpose of sending an Inform message to the remote engine.
>

I am missing something here (apart from time to read messages promptly:-(

Why do you need the remote engine-id?  An Inform sends information about itself
so the contextEngineID is itself and the authoritativeEngineID is that of the
sender, again itself.  So if all you do is receive Informs, you need not have an
EngineID (although there is probably a clause buried in STD62 somewhere that
says you must)

Tom Petch

> After sending the discovery packet to the requested target and upon
> receiving an incoming packet:
>
> Should the (UDP) port also be used (in addition to IP address) for
> matching response to the request in this case?
>
> In other words - when a cache is used to store remote
> engine-ids information,
>
> should the mapping be of the form:    engine-id -> ip-address
> or                     engine-id -> ip-address, UDP port
>
> In case the SNMP engine supports second option, if the remote
> engine-id sends a response to the discovery packet from a port
> different from the port on which it got the request, the SNMP
> engine will ignore the response and the discovery process will
> fail. Hence the importance of interoperability in this case.
>
>
>
> Thank you
>
> Tammy Alper
>
_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

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

---

From: Chris Elliott <[email-masked]>
Date: Thu, 5 Apr 2007 15:47:35 -0400 (EDT)

Tom,

In all SNMPv3 USM communications where a response is expected the 
authoritativeEngineID is the SNMP entity receiving the operation to which 
a response is expected. Therefore, the authoritativeEngineID for an Inform 
operation is that of the recipient.

As traps don't require a response, the authoritativeEngineID is that of 
the sender.

A trap receiver could get away without an engineID, but not an inform 
receiver.

Chris.

P.S. Tammy--I agree with Burt--cache the port. If you look at the 
SNMP-TARGET-MIB, you'll see that the typical transport domain for SNMP 
(snmpUDPDomain) requires a transport address that includes the IPv4 
address and the UDP port number.

-- 
Chris Elliott  CCIE# 2013       |         |
Customer Diagnostic Engineer   |||       |||
RTP, NC, USA                  |||||     |||||
919-392-2146              .:|||||||||:|||||||||:.
[email-masked]        c i s c o S y s t e m s

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 5 Apr 2007 13:14:34 -0700

Hi -

> From: "tom.petch" <[email-masked]>
> To: "Tammy Alper" <[email-masked]>; <[email-masked]>
> Sent: Thursday, April 05, 2007 9:12 AM
> Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process
...
> EngineID (although there is probably a clause buried
...

See RFC 3412 clause 7.1 on "Prepare an Outgoing SNMP Message"
There, in point 9, it says:

   9) If the PDU is from the Confirmed Class or the Notification Class,
      then:

      a) If the PDU is from the Unconfirmed Class, then securityEngineID
         is set to the value of this entity's snmpEngineID.

         Otherwise, the snmpEngineID of the target entity is determined,
         in an implementation-dependent manner, possibly using
         transportDomain and transportAddress.  The value of the
         securityEngineID is set to the value of the target entity's
         snmpEngineID.

There really is a need to determine the remote engine id.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Apr 2007 07:41:49 +0200

> There really is a need to determine the remote engine id.

In an implementation specific manner. My understanding is that the
determined securityEngineID is passed via the generateRequestMsg() ASI
into the security subsystem. And since the transport security model
does not seem to need a concept of authoritative engines, I think as
an implementor I can come up with an easy implementation-dependent way
of determining the remote engine id, no?

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 5 Apr 2007 23:02:38 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, April 05, 2007 10:41 PM
...
> of determining the remote engine id, no?

Of course.  I think it's quite clear that the RFC doesn't prescribe
the use of a specific mechanism here, explicitly leaving it as a
matter of implementation choice.  

However, I'm not sure it would make sense to limit an
implimentation to support only the transport security model.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Apr 2007 11:34:22 +0200

> implimentation to support only the transport security model.

Sure, but since this determination is implementation specific, I do
not really see a problem. And in the code bases I am familiar with,
the issue really is a non-issue.

/js

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 6 Apr 2007 10:55:02 -0700 (PDT)

HI,

This issue and associated misunderstandings have been around
since the development of SNMPv3/USM. There are many "urban legends"
that go with SNMPv3 engineIDs used to identify management info
and used in the contextEngineID field in ALL SNMPv3 messages,
and the SNMPv3 engineID used in the msgAuthoritativeEngineID
used presently in ONLY SNMPv3/USM messages.

Both uses of engineIDs are associated with a transport address,
and for the Internetprotocol, this means an IP address and port.

By the way, it is certainly the case that USM is defined as the
following:
   GET/SET/GETNEXT/GETBULK/INFORM - msgAuthoritativeEngineID contains
         the value of the receiver
   RESPONSE/v2TRAP - msgAuthoritativeEngineID contains the value
         of the sender
However, these choices are "arbitrary" and could have been switched.
The reason they are what they are are so that the shared clock
can be synchronized through "normal" message exchange without
"extra" messages. Unfortunately, this approach has proven to
be costly for INFORMs. Many people who have experience with
SNMPv3/USM wish that INFORMs used the senders engineID.
But, SNMPv3 is defined as it is, and there is too much
resistance to change anything about SNMPv3/USM.

Note that SNMP3v/USM requires engineIDs to perform SNMPv3
operations, and an engineID discovery technique is described
in the USM RFC (RFC 3414). This technique is not without
problems, and does not work for proxies.

Other SNMPv3 security models, such as ISMS do use the
the msgAuthoritativeEngineID field, since security is
done differently.

Hope this helps.

Regards,
/david t. perkins

On Thu, 5 Apr 2007, Chris Elliott wrote:
> authoritativeEngineID is the SNMP entity receiving the operation to which a 
> response is expected. Therefore, the authoritativeEngineID for an Inform 
> As traps don't require a response, the authoritativeEngineID is that of the 
> sender.
>
> (snmpUDPDomain) requires a transport address that includes the IPv4 address 
> and the UDP port number.
>

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 6 Apr 2007 11:06:59 -0700 (PDT)

HI,

Commenting on Juergen's last point....

For INFORMs, it's "just a special case" piece of code that needs
to be written. It is not obvious, but once you get the concept,
a coder of an INFORM generator realizes that a cache must be
implemented that maps transport address to engineIDs. It's
really sort of nasty. In processing sending notifications
that are INFORMs, if there is no transport to security engineID
mapping, the notification sending code must first do a EngineID
discovery. After the code has that mapping, it can complete
the procedure for notification delivery.

Regards,
/david t. perkins

---

From: "David Harrington" <[email-masked]>
Date: Fri, 6 Apr 2007 15:09:42 -0400

Hi,

> From: David T. Perkins [mailto:[email-masked]] 
> 

I believe Dave meant to say "do not use".

A few minor corrections:
1) ISMS is not a security model
2) It is not a requirement that other security models do not use
msgAuthoritativeEngineID, so "do not use" should probably be "may
choose not to use"

So I think this would be more accurate:
Other security models, such as the Transport Security Model being
developed in the ISMS WG, may choose to not use a
msgAuthoritativeEngineID field, since security is done differently. 

(For SNMPv3 processing, however, other security models will still need
to set the value of securityEngineID for the processIncomingMessage
ASI, because RFC3412 section 7.2 13a checks the value of
securityEngineID. The Transport Security Model sets it to the local
snmpEngineID, so the 7.2 13a condition does not trigger.)

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Apr 2007 10:15:04 +0200

> msgAuthoritativeEngineID field, since security is done differently. 

Since msgAuthoritativeEngineID is a USM specific header field, the
above text does seem relatively pointless do me.

/js

---

From: "tom.petch" <[email-masked]>
Date: Wed, 11 Apr 2007 19:03:52 +0200

Thanks to you all for putting me straight.  As you may gather, I have been
contemplating Informs again, wondering about the various posts that have
considered their compatability with TMSM.

>From that, another query.  What happens to port numbers with TMSM?  At present,
SNMP applications use 161 and 162 (mostly) which then becomes part of the key
for selecting engineID.  Will applications still use this at the ASI to the
Dispatcher?  If and when does this change to a secure transport port?

Tom Petch

----- Original Message -----
From: "David T. Perkins" <[email-masked]>
To: "Chris Elliott" <[email-masked]>
Cc: "tom.petch" <[email-masked]>; "Tammy Alper" <[email-masked]>;
<[email-masked]>
Sent: Friday, April 06, 2007 7:55 PM
Subject: Re: [Isms] Question regarding SNMPv3 engine-id discovery process

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Apr 2007 08:49:49 +0200

> Dispatcher?  If and when does this change to a secure transport port?

We currently use a user supplied port number and we expect that a
default port number for a secure transport model will be allocated by
the secure transport model specification. In other words, this is part
of the SSH transport model specification to spell out (together with
the proper TDomain definitions).

Since we use TDomain/TAddress in the ASIs, nothing is going to change
about the ASIs and the internals of the Dispatcher as far as I can
tell.

/js

---

From: "tom.petch" <[email-masked]>
Date: Wed, 25 Apr 2007 15:08:46 +0200

The impression I have is that for SNMP over SSH (and most likely for other such
session transports)  there will be but one port, for both Notifications and
Requests.

In which case, I think that TMSM s3.1.1 should mention this, that the
application can no longer use port 161 and 162 to differentiate the traffic;
they will, perforce, share the session (assuming the other session selection
parameters are the same).  Unless the intention is for the application to still
use 161 and 162 but for these to be translated somewhere in the ASIs to the SSH
port; seema unlikely.

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 12, 2007 8:49 AM
Subject: Re: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-id
discovery process

---

From: "David Harrington" <[email-masked]>
Date: Wed, 25 Apr 2007 11:24:22 -0400

The SNMP applications (Commnd Requetser, Command Responder, et al)
specify the transport addresses, possibly based on pre-configured MIBs
or other administrative configuration.

An NMS may allow an administrator to decide which ports, and some NMSs
may allow the ports for both types of traffic to be the same, others
may require separate ports.

I expect that on the NMS side, a software application may force the
decision about whether RR runs on a separate transport from
notifications, because the software code that supports handling
asynchronous messages might be very different than the software code
for handling response/requests. I consider this fairly likely because
a) the processing required for event-driven management can be quite
different for polling-driven management, and b) SNMP has traditionally
used two ports to differentiate the different types of traffic, so
existing SNMP applications might find it easier to migrate to SSH-TM
using separate ports. 

The question we need to be conerned with is should we have IANA assign
one or more default ports for SSH-TM. It is my intention to ask for
one default port.

The mention of 161 and 162 was only an example of how traffic can be
separated by port number; I was not recommending the use of 161 and
162.

I will try to make that clear in the SSH transport model. I will check
the TMSM to see if I need to clarify anything there.

dbh

> From: tom.petch [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 9:09 AM
> Cc: [email-masked]
> Subject: Re: TMSM and Port was Re: [Isms] Question regarding 
> SNMPv3engine-iddiscovery process
> 
> > > From that, another query.  What happens to port numbers 
> with TMSM?  At
> present,
> > > SNMP applications use 161 and 162 (mostly) which then 
> becomes part of the
> key

---

From: "tom.petch" <[email-masked]>
Date: Fri, 27 Apr 2007 18:19:29 +0200

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."

(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.

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.

Tom Petch