Subject: [Isms] Request-response pairs

From: "David Harrington" <[email-masked]>
Date: Tue, 27 Feb 2007 13:26:37 -0500

Hi,

I realize that I may have made comments that are incorrect.
I had been assuming that the pairing of requesta and responses was
handled in the message processing subsystem. That would be incorrect.
That pairing is done at the application level.

So to handle a session-close and session-open between the time of
request and the time of response means sharing information between the
transport subsystem and the application subsystem - two opposite ends
of the SNMP architecture. So much for modularity.

If this is a requirement, then I think we can sucessfully say that
SNMP should not use lower layer security services, but should do
everything internally like USM does.

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

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 28 Feb 2007 18:49:43 -0500

> That pairing is done at the application level.

I was wondering about that.

> of the SNMP architecture. So much for modularity.

Hm?  If the session is closed between when the request is received and when 
the response is ready, you lose.  The session over which you must send the 
response no longer exists.

> everything internally like USM does.

I think that's being a little extreme.  We can solve the problem without 
throwing everything away and starting over, and I think we should.  All 
that is required si for the SM to send some opaque thing up the stack to 
the application, which is sent back down with the response.  This thing 
contains whatever the SM needs to insure the response goes back over the 
same session, if that is required  (and the SM gets to decide this, or 
perhaps the SM specification gets to specify this).  For messages that are 
not responses, the "thing" is omitted, which tells the SM it can use any 
session it likes.

BTW, this is still a security issue - it is the SM that gets to decide 
whether the same session is needed, not the transport mapping, and thus it 
is the SM that needs to toss an opaque object "over the fence" so to speak.

-- Jeff