Subject: Re: [Isms] wg last call on isms document set -tmsm

From: "David Harrington" <[email-masked]>
Date: Wed, 3 Dec 2008 19:18:53 -0500

Hi, 

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> 
> 3.2.2.1.  securityName and securityLevel Mapping
> 
>    include from one to four ASCII characters, not including a 
> ":" (ASCII
> 
> ** this would allow the use of vertical tab and BEL:-)  I 
> think that the ASCII
> character set should be more restricted, to one of the well 
> known sets, both in
> this section and in s.8

Please recommend an appropriate well known set.

> 
> 6.2.2 generateResponseMessage
> 
> ** this has lots of references to steps, first appeared in 
> tmsm-13, which are
> not in the I-D

Huh? The word "steps" is used once in the whole document, and not in
this section. This sections discusses the source of the new IN
parameters, and the destination of the new OUT parameters. I do not
see the problem.

dbh

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

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 05 Dec 2008 13:57:16 -0800

>>>>> On Thu, 20 Nov 2008 18:19:46 +0100, "tom.petch" <[email-masked]> said:

tp> This seems to be a cache with an entry per message, like
tp> securityStateReference, but at odds with the description in eg tmsm
tp> s 5.2 which says " The tmStateReference cache will typically remain
tp> valid for the duration of the transport session, and hence may be
tp> used for several messages."  or tsm s.3 "This document defines the
tp> requirements for a cache to handle the longer-term transport state
tp> information,..."

I'm not sure this was ever resolved in the thread.  Here's the issue:

In the following (slightly abbreviated for size; there are more blocks
than are depicted here) architecture, a request comes in through SSHTM
and is handled by the app (the agent) and then back out through the
SSHTM:

  Request coming in:
    +-------+     +------------+     +----+     +-----+     +-----+
    | SSHTM | --> | Dispatcher | --> | MP | --> | TSM | --> | App |
    +-------+     +------------+     +----+     +-----+     +-----+
                                                               |
  Response going back out:                                     |
    +-------+     +------------+     +----+     +-----+        |
    | SSHTM | <-- | Dispatcher | <-- | MP | <-- | TSM | <------/
    +-------+     +------------+     +----+     +-----+

The securityStateReference used by RFC34* was designed for the  to let
the TSM tag on extra information to the PDU being handled by the App.
This is done because in a multi-threaded type of environment more than
one request may be processed at once so state is needed.  It turns out,
based on how things have been designed, that this is also true for
transports.  Thus we have two different "caches" that affect different
parts of the processing:

  | ------------------- tmStateReference --------- | --- secStateRef -- |

  Request coming in:
    +-------+     +------------+     +----+     +-----+     +-----+
    | SSHTM | --> | Dispatcher | --> | MP | --> | TSM | --> | App |
    +-------+     +------------+     +----+     +-----+     +-----+
                                                               |
  Response going back out:                                     |
    +-------+     +------------+     +----+     +-----+        |
    | SSHTM | <-- | Dispatcher | <-- | MP | <-- | TSM | <------/
    +-------+     +------------+     +----+     +-----+

The tmStateReference sort of serves as a cache that is attached to a
message, because it's embedded within the secStateReference and
extracted back out for the outgoing response.  In this is one piece of
information that keeps the tmStateReference from being a
session-long-lived cache: the tmSameSecurity flag.  This flag will be on
or off depending on the message that is being dealt with.  Thus, the
tmStateReference *must* be a per-message cache because tmSameSecurity
will be potentially different if multiple messages are being handled by
the system at once.

In the end, I'm not sure it matters too much.  As a WG we've hacked this
on to the architecture because there was no other way to pass
information from the TSM to the SSHTM (or other).  There is nothing
stopping a real implementation, as far as I know, from making the
tmSameSecurity flag be part of it's API or part of it's PDU structure or
...  Just because the document flags the tmStateReference as short lived
(now; you're right it didn't used to) doesn't mean an implementation has
to do lots of malloc/reference-tracking/demallocing if it doesn't want
to.  There are many ways such information can be implemented.

Is there still documentation that refers to the tmStateReference as a
long-lived cache?  If so, it needs to be fixed.

--
Wes Hardaker
Sparta, Inc.

---

From: "tom.petch" <[email-masked]>
Date: Mon, 8 Dec 2008 17:01:54 +0100

<inline>
Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 04, 2008 1:18 AM
Subject: Re: [Isms] wg last call on isms document set -tmsm

> > From: tom.petch [mailto:[email-masked]]
<snip>
> parameters, and the destination of the new OUT parameters. I do not

My humble apologies, my language was very sloppy; I should have said 'step' and
not 'steps' as in

"    IN   transportDomain         -- (NEW) destination transport domain
     IN   transportAddress        -- (NEW) destination transport address
     IN   messageProcessingModel -- SNMPv3 Message Processing
                                       -- Model
     IN   globalData             -- msgGlobalData from step 7
     IN   maxMessageSize         -- from msgMaxSize (step 7c)
     IN   securityModel          -- as determined in step 7e
     IN   securityEngineID       -- the value of snmpEngineID
     IN   securityName           -- on behalf of this principal
     IN   securityLevel          -- for the outgoing message
     IN   scopedPDU              -- as prepared in step 6)
     IN   securityStateReference -- as determined in step 2
     OUT  securityParameters     -- filled in by Security Module"

where there are references to 'step 7', '(step 7c), 'step 6)' and 'step 2',
references
which I cannot relate to any other part of this I-D.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Mon, 8 Dec 2008 17:01:05 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "David Harrington"
<[email-masked]>; "Wes Hardaker" <[email-masked]>
Sent: Friday, December 05, 2008 10:57 PM
Subject: Re: wg last call on isms document set - tsm b

> long-lived cache?

Wes

err.... I thought that was what I was quoting, from the start of this message

"                                                     the description in eg tmsm
> tp> requirements for a cache to handle the longer-term transport state

I am reading 'duration of transport session' and 'longer-term transport state'
as implying a 'long-lived cache' but perhaps I am misreading it.:-(

Guess who.

> If so, it needs to be fixed.
>
> Wes Hardaker
> Sparta, Inc.

---

From: "David Harrington" <[email-masked]>
Date: Mon, 8 Dec 2008 13:17:17 -0500

Ah. Now I see what you refer to. I will fix these.

dbh 

> Sent: Monday, December 08, 2008 11:02 AM
> To: David Harrington; [email-masked]
> Cc: Juergen Schoenwaelder

---

From: "David Harrington" <[email-masked]>
Date: Mon, 8 Dec 2008 13:32:43 -0500

Hi 

tmStateReference refers to some "tmState" that holds implementation-
and model-dependent information related to a transport model.

Most of the information we identify as part of the tm state can be
long-lived, and used across multiple messages. Some of the information
may be more message-centric, such as tmSameSecurity and (maybe)
tmRequestedSecurityLevel.

If we try to parse out every variable based on its lifetime, then I
think the cure will be worse than the disease.

Keep in mind that the tmStateReference (and the implicit tmState) is
implementation-dependent and model-dependent. As a result, it is very
difficult to be definitive about most of this information, and it
really makes very little difference to interoperability since the
information is not on-the-wire.

The only way we can try to be definitive is to define a MIB module and
try to clearly define each variable in the MIB. We have tried this
repeatedly and have not been able to reach consensus on the
assumptions about each piece and their mappings to other things beyond
our control. But, hey, the next revision will be even-numbered, so
that means we should have a MIB module again (and then we'll remove it
again on the next odd-numbered revision, ad nauseum ...)

If you have specific points in the text you think should be reworded,
please suggest alternate text. Please be explicit about the specific
text you want changed and how you want it to read.

As editor, if I believe the proposed change represents WG consensus, I
will make the change. If I think it does not represent consensus or I
do not undertand the requested edits, I will ask the chair for
directions.

dbh

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of tom.petch
> Sent: Monday, December 08, 2008 11:01 AM
> To: Wes Hardaker
> Cc: [email-masked]
> Subject: Re: [Isms] wg last call on isms document set - tsm b
> 
> > >>>>> On Thu, 20 Nov 2008 18:19:46 +0100, "tom.petch" 
> <[email-masked]>
> said:
> >
+-----+
> >     | SSHTM | --> | Dispatcher | --> | MP | --> | TSM | --> | App
|
+-----+
> >   | ------------------- tmStateReference --------- | --- 
+-----+
> >     | SSHTM | --> | Dispatcher | --> | MP | --> | TSM | --> | App
|
+-----+

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Dec 2008 21:56:04 +0100

> again on the next odd-numbered revision, ad nauseum ...)

Speaking as technical contributor: A MIB module is not the answer here
because the state cache is a conceptual and implementation internal
data structure. There is no point in exporting such data structures
through a MIB module nor is the SMIv2 the adequate tool to define
internal data structures. For all those implementors whose code base
does not follow the ASIs, most of this discussion is rather academic.
We need to find the point where the behaviour is clear enough so that
implementors do the right thing when they translate the architecture
back into their code bases. At the end of the day, the goal is to come
up with interoperable implementations and I am concerned that this WG
strives for some level of perfection for Proposed Standard and might
loose implementors on the long way it takes.

/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/>
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms