From isms-bounces@ietf.org Wed Dec 3 16:19:03 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91AA028C1B8; Wed, 3 Dec 2008 16:19:03 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB393A677D for ; Wed, 3 Dec 2008 16:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_20=-0.74, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozbhBM+W1vaN for ; Wed, 3 Dec 2008 16:19:01 -0800 (PST) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 0D4903A6452 for ; Wed, 3 Dec 2008 16:19:00 -0800 (PST) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA06.westchester.pa.mail.comcast.net with comcast id mkCZ1a04u0ldTLk56oJv5J; Thu, 04 Dec 2008 00:18:55 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA04.westchester.pa.mail.comcast.net with comcast id moJt1a00E0UQ6dC3QoJtsl; Thu, 04 Dec 2008 00:18:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=9WVCibXvPVEA:10 a=r2zT34aMsLsA:10 a=LfLVdwLZUvs3qIlEv6gA:9 a=F33EPyjYTRDIIGt5a4eWoZCH1TcA:4 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <20081104081320.GA26802@elstar.local> <000c01c94a25$db2bdca0$0601a8c0@allison> Date: Wed, 3 Dec 2008 19:18:53 -0500 Message-ID: <005801c955a5$e3cb3500$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000c01c94a25$db2bdca0$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AclK2y/6ZrLxG6+WQkOlvvo3mLT69AKwqXlg Subject: Re: [Isms] wg last call on isms document set -tmsm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > > 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 Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Dec 3 16:40:37 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41CE33A6BE7; Wed, 3 Dec 2008 16:40:37 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7413A6BE7 for ; Wed, 3 Dec 2008 16:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AUcE+wGTVMO for ; Wed, 3 Dec 2008 16:40:35 -0800 (PST) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 5BB203A6BE4 for ; Wed, 3 Dec 2008 16:40:35 -0800 (PST) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA02.westchester.pa.mail.comcast.net with comcast id moMj1a00F16LCl052ofrsV; Thu, 04 Dec 2008 00:39:51 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA06.westchester.pa.mail.comcast.net with comcast id mogW1a00G0UQ6dC3SogWeU; Thu, 04 Dec 2008 00:40:31 +0000 X-Authority-Analysis: v=1.0 c=1 a=jXmknW7A5Y8A:10 a=2uaOcNeAYjEA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=jZqP59UZo1QUy_soPaAA:9 a=oVQHfaGor4qx9iEJ8q8A:7 a=FFpGTZ2MCOogMdUoiTi2xUG1XXEA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=Y6qChIQXU1wA:10 a=zeshHG33Dl4A:10 a=lZB815dzVvQA:10 a=PkPobLqB3P0A:10 From: "David Harrington" To: , References: <20070907072640.GA3495@elstar.local> <029d01c7f158$a7b4ab80$0601a8c0@pc6> Date: Wed, 3 Dec 2008 19:40:30 -0500 Message-ID: <005901c955a8$e9287820$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <029d01c7f158$a7b4ab80$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcfxYiaZt1rwCDbrQRi9x5kTIUNvzFkRYlzQ Subject: Re: [Isms] isms core documents last call status X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I am editing the tmsm document. Tom is obviously not satisfied with the tmsm document. He thinks the architecture document should be clearer than it is. I do not know what I am supposed to change. He would like much more detail about how values are transformed, but that is extremely dependent on the specific models. The whole prefix thing is TSM-dependent; the joe@example.com is SSH-transport-model dependent. Moving those details into tmsm would totally violate the whole modularity principle. A discussion of what can be achieved by mixing and matching existing models also seems wrong in the architecture document. We have a whole section on "Coexistence, Security Parameters, and Access Control" that discusses this from an architectural level. It is my intention to ignore this email from Tom, unless you tell me to something specific. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Friday, September 07, 2007 10:08 AM > To: j.schoenwaelder@jacobs-university.de; isms@ietf.org > Subject: Re: [Isms] isms core documents last call status > > Juergen > > You are right that I have commented on tmsm and I would > regard my comments on > the use of security name and security level (and I > deliberately do not use the > RFC3411 terminology here) therein as technical and (as yet) > unresolved. Jeffrey > has rightly pointed out that words can be found to support a > position - eg > sshtm - but I think that an architecture document should be > clearer than that, > particularly over the issue of values being transformed. > Also, it is not > obvious what can and cannot be achieved, as with USM over > SSH, which currently > appears infeasible. > > The sshtm I-D is more restrictive and so is not such a > problem; but I can see a > future working group trying to make sense of tmsm in the way > we have tried to > make sense of eg authoritative, context engines, informs etc > > Tom Petch > > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Sent: Friday, September 07, 2007 9:26 AM > Subject: [Isms] isms core documents last call status > > > > Hi, > > > > the WG last call on the core ISMS documents has so far > resulted in the > > following reviews (let me know if the data below is incorrect): > > > > draft-ietf-isms-tmsm-09.txt BW, TP, JS > > draft-ietf-isms-transport-security-model-05.txt BW, TP, DR, JS > > draft-ietf-isms-secshell-08.txt BW, WH, JS > > > > [BW] = Bert Wijnen > > [TP] = Tom Petch > > [DR] = Dan Romascanu > > [JS] = Joe Salowey > > [WH] = Wes Hardacker > > > > While some very good people reviewed the documents, it would surely > > not hurt to have some additional reviews. If there are more people > > here who have read the documents but kept silence since they did not > > have an issue to post, please let me know. If you did not manage to > > read the documents due to vacation time, please still consider to > > review the documents and send comments by the end of next week > > (September 15th) or contact me if you need more time. > > > > I am now going through the discussions in detail in order > to classify > > the issues that were brought up to see which are editorial, > which are > > technical and if there are any issues where the resolution is not > > clear. Once I have assembled this list, I will post it here for WG > > review and ask Dave to revise the documents. I hope we can > deliver the > > core documents to the IESG soon. > > > > Since I have to write up the paper work for submission to > the IESG, I > > am also interested to hear about people planning to implement or > > experiment with the ISMS technology. While there have been several > > indications in the past, it surely helps me if people interested to > > implement/experiment contact me again so that I have an up-to-date > > view on things. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Dec 5 02:46:59 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8083A6BEE; Fri, 5 Dec 2008 02:46:59 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A25F3A6AFB for ; Fri, 5 Dec 2008 02:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPwcxNxoHTyO for ; Fri, 5 Dec 2008 02:46:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8566D3A6BEE for ; Fri, 5 Dec 2008 02:46:57 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D290BC0036; Fri, 5 Dec 2008 11:46:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4lILZVGo6R4t; Fri, 5 Dec 2008 11:46:47 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BDE8C0111; Fri, 5 Dec 2008 11:46:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4F7E989EDC2; Fri, 5 Dec 2008 11:46:46 +0100 (CET) Date: Fri, 5 Dec 2008 11:46:46 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20081205104646.GA13508@elstar.local> Mail-Followup-To: David Harrington , isms@ietf.org References: <20070907072640.GA3495@elstar.local> <029d01c7f158$a7b4ab80$0601a8c0@pc6> <005901c955a8$e9287820$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <005901c955a8$e9287820$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] isms core documents last call status X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Wed, Dec 03, 2008 at 07:40:30PM -0500, David Harrington wrote: > I am editing the tmsm document. > Tom is obviously not satisfied with the tmsm document. He thinks the > architecture document should be clearer than it is. I do not know what > I am supposed to change. > > He would like much more detail about how values are transformed, but > that is extremely dependent on the specific models. The whole prefix > thing is TSM-dependent; the joe@example.com is SSH-transport-model > dependent. Moving those details into tmsm would totally violate the > whole modularity principle. I agree. > A discussion of what can be achieved by mixing and matching existing > models also seems wrong in the architecture document. We have a whole > section on "Coexistence, Security Parameters, and Access Control" that > discusses this from an architectural level. I agree. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Dec 5 12:09:40 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C162A3A6C93; Fri, 5 Dec 2008 12:09:40 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C553D3A6C89 for ; Fri, 5 Dec 2008 12:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[AWL=2.184, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUJgG3lUV5h7 for ; Fri, 5 Dec 2008 12:09:39 -0800 (PST) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id ECDD83A6C81 for ; Fri, 5 Dec 2008 12:09:38 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 50AE6399B3D; Fri, 5 Dec 2008 12:09:34 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20070907072640.GA3495@elstar.local> <029d01c7f158$a7b4ab80$0601a8c0@pc6> <005901c955a8$e9287820$0600a8c0@china.huawei.com> Date: Fri, 05 Dec 2008 12:09:34 -0800 In-Reply-To: <005901c955a8$e9287820$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 3 Dec 2008 19:40:30 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] isms core documents last call status X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 3 Dec 2008 19:40:30 -0500, "David Harrington" said: DH> Tom is obviously not satisfied with the tmsm document. He thinks the DH> architecture document should be clearer than it is. I do not know what DH> I am supposed to change. Although I do think the documents are a bit hard to read if you're not familiar with the history, I don't think that changes can be made that would significantly improve things. The IETF has constantly had issues with documentation of modular systems. We tend to define lots of small documents that interrelate but we optimize for future expandability/replacability over readability. E.G. we must be able to have the TMSM and SSHTM documents work with a new TSM2 document. Because of this it means things are hard to describe in one place. DH> He would like much more detail about how values are transformed, but DH> that is extremely dependent on the specific models. The whole prefix DH> thing is TSM-dependent; the joe@example.com is SSH-transport-model DH> dependent. Moving those details into tmsm would totally violate the DH> whole modularity principle. And that's a prime example. The "ssh:" prefix is, and should be, specific to just the TSM document. The joe@ prefix is very ssh specific and shouldn't go into the other documents. I can see how this can lead the reader into a bit of confusion until they shuffle through it all. But to add the details into the other documents would be wrong, IMHO. DH> It is my intention to ignore this email from Tom, unless you tell me DH> to something specific. I agree with this decision. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Dec 5 13:57:23 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C7F3A67B5; Fri, 5 Dec 2008 13:57:23 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36493A67B5 for ; Fri, 5 Dec 2008 13:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=1.092, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BCQqfDlIMSF for ; Fri, 5 Dec 2008 13:57:20 -0800 (PST) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id C30A33A6403 for ; Fri, 5 Dec 2008 13:57:20 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 46113399B3D; Fri, 5 Dec 2008 13:57:16 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <20081104081320.GA26802@elstar.local> <001001c94b34$4bf80da0$0601a8c0@allison> Date: Fri, 05 Dec 2008 13:57:16 -0800 In-Reply-To: <001001c94b34$4bf80da0$0601a8c0@allison> (tom petch's message of "Thu, 20 Nov 2008 18:19:46 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] wg last call on isms document set - tsm b X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Thu, 20 Nov 2008 18:19:46 +0100, "tom.petch" 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. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Dec 8 10:08:56 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3A628C12E; Mon, 8 Dec 2008 10:08:56 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2C6C28C12E for ; Mon, 8 Dec 2008 10:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.656 X-Spam-Level: X-Spam-Status: No, score=-0.656 tagged_above=-999 required=5 tests=[AWL=-1.257, BAYES_50=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kJ8hqH00C3d for ; Mon, 8 Dec 2008 10:08:54 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id CB91C28C128 for ; Mon, 8 Dec 2008 10:08:53 -0800 (PST) X-Trace: 115239184/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.105/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.105 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAE/xPEk+vGlp/2dsb2JhbACDQ4lYwXoHgn4 X-IronPort-AV: E=Sophos;i="4.33,736,1220223600"; d="scan'208";a="115239184" X-IP-Direction: IN Received: from 1cust105.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.105]) by smtp.pipex.tiscali.co.uk with SMTP; 08 Dec 2008 18:08:45 +0000 Message-ID: <012e01c95957$b277eb00$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <20081104081320.GA26802@elstar.local><000c01c94a25$db2bdca0$0601a8c0@allison> <005801c955a5$e3cb3500$0600a8c0@china.huawei.com> Date: Mon, 8 Dec 2008 17:01:54 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] wg last call on isms document set -tmsm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Tom Petch ----- Original Message ----- From: "David Harrington" To: Sent: Thursday, December 04, 2008 1:18 AM Subject: Re: [Isms] wg last call on isms document set -tmsm > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > > > > 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. 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 > > dbh _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Dec 8 10:08:59 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C243428C132; Mon, 8 Dec 2008 10:08:59 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300F428C132 for ; Mon, 8 Dec 2008 10:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJEAOj2nKaOZ for ; Mon, 8 Dec 2008 10:08:53 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id EEF7328C11A for ; Mon, 8 Dec 2008 10:08:52 -0800 (PST) X-Trace: 115239173/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.105/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.105 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAE/xPEk+vGlp/2dsb2JhbACDQ4lYwXoHgn4 X-IronPort-AV: E=Sophos;i="4.33,736,1220223600"; d="scan'208";a="115239173" X-IP-Direction: IN Received: from 1cust105.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.105]) by smtp.pipex.tiscali.co.uk with SMTP; 08 Dec 2008 18:08:43 +0000 Message-ID: <012d01c95957$b1516c60$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <20081104081320.GA26802@elstar.local><001001c94b34$4bf80da0$0601a8c0@allison> Date: Mon, 8 Dec 2008 17:01:05 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] wg last call on isms document set - tsm b X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "Wes Hardaker" To: "tom.petch" Cc: ; ; "David Harrington" ; "Wes Hardaker" Sent: Friday, December 05, 2008 10:57 PM Subject: Re: wg last call on isms document set - tsm b > >>>>> On Thu, 20 Nov 2008 18:19:46 +0100, "tom.petch" 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? Wes err.... I thought that was what I was quoting, from the start of this message " 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 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. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Dec 8 10:17:26 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183BE3A67D6; Mon, 8 Dec 2008 10:17:26 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35573A67D6 for ; Mon, 8 Dec 2008 10:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9-xWzy63tPB for ; Mon, 8 Dec 2008 10:17:24 -0800 (PST) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id D87D53A67BD for ; Mon, 8 Dec 2008 10:17:23 -0800 (PST) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA06.westchester.pa.mail.comcast.net with comcast id of8K1a00G0bG4ec56iHJaG; Mon, 08 Dec 2008 18:17:18 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA03.westchester.pa.mail.comcast.net with comcast id oiHH1a00A0UQ6dC3PiHHfX; Mon, 08 Dec 2008 18:17:17 +0000 From: "David Harrington" To: "'tom.petch'" , References: <20081104081320.GA26802@elstar.local><000c01c94a25$db2bdca0$0601a8c0@allison> <005801c955a5$e3cb3500$0600a8c0@china.huawei.com> <012e01c95957$b277eb00$0601a8c0@allison> Date: Mon, 8 Dec 2008 13:17:17 -0500 Message-ID: <02b701c95961$34032190$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <012e01c95957$b277eb00$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AclZYARCujO6fUBzS1u3n2nHmvH7jgAAQPyA Subject: Re: [Isms] wg last call on isms document set -tmsm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Ah. Now I see what you refer to. I will fix these. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Monday, December 08, 2008 11:02 AM > To: David Harrington; isms@ietf.org > Cc: Juergen Schoenwaelder > Subject: Re: [Isms] wg last call on isms document set -tmsm > > > Tom Petch > > ----- Original Message ----- > From: "David Harrington" > To: > Sent: Thursday, December 04, 2008 1:18 AM > Subject: Re: [Isms] wg last call on isms document set -tmsm > > > -----Original Message----- > > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > > > > > > > > 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. > > 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 > > > > > dbh > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Dec 8 10:32:54 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BFA928C120; Mon, 8 Dec 2008 10:32:54 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2E2A28C12B for ; Mon, 8 Dec 2008 10:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pN5YqvkqD+y6 for ; Mon, 8 Dec 2008 10:32:52 -0800 (PST) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 4001E3A688A for ; Mon, 8 Dec 2008 10:32:50 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA06.westchester.pa.mail.comcast.net with comcast id ogSp1a0240SCNGk56iYkQY; Mon, 08 Dec 2008 18:32:44 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id oiYj1a00S0UQ6dC3ViYj66; Mon, 08 Dec 2008 18:32:44 +0000 From: "David Harrington" To: "'tom.petch'" , "'Wes Hardaker'" References: <20081104081320.GA26802@elstar.local><001001c94b34$4bf80da0$0601a8c0@allison> <012d01c95957$b1516c60$0601a8c0@allison> Date: Mon, 8 Dec 2008 13:32:43 -0500 Message-ID: <02c101c95963$5c5553a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <012d01c95957$b1516c60$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AclZYAkHmqRhXne+Q8uKpR0eIcGW/QAAWs/g Cc: isms@ietf.org Subject: Re: [Isms] wg last call on isms document set - tsm b X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org 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 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of tom.petch > Sent: Monday, December 08, 2008 11:01 AM > To: Wes Hardaker > Cc: isms@ietf.org > Subject: Re: [Isms] wg last call on isms document set - tsm b > > ----- Original Message ----- > From: "Wes Hardaker" > To: "tom.petch" > Cc: ; ; > "David Harrington" > ; "Wes Hardaker" > Sent: Friday, December 05, 2008 10:57 PM > Subject: Re: wg last call on isms document set - tsm b > > > >>>>> On Thu, 20 Nov 2008 18:19:46 +0100, "tom.petch" > > 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? > > Wes > > err.... I thought that was what I was quoting, from the start > of this message > > " 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 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. > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Dec 9 03:30:39 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549043A6802; Tue, 9 Dec 2008 03:30:39 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5ACD3A6802 for ; Tue, 9 Dec 2008 03:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWSLe0-mJ2Jo for ; Tue, 9 Dec 2008 03:30:38 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id DA6263A679C for ; Tue, 9 Dec 2008 03:30:37 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mB9BU9D3027789; Tue, 9 Dec 2008 13:30:27 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Dec 2008 13:29:58 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Dec 2008 13:29:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 13:29:55 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720280D536@vaebe104.NOE.Nokia.com> In-Reply-To: <016201c9515c$da8414a0$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] One additional comment for transport-security-model-10 Thread-Index: AclRZSzyjudG+bxpRFWv00RFaqwSFwIjBXCA References: <1696498986EFEC4D9153717DA325CB720264FF14@vaebe104.NOE.Nokia.com> <016201c9515c$da8414a0$0601a8c0@allison> From: To: , X-OriginalArrivalTime: 09 Dec 2008 11:29:55.0320 (UTC) FILETIME=[75AF8F80:01C959F1] X-Nokia-AV: Clean Subject: Re: [Isms] One additional comment for transport-security-model-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Tom Petch wrote: > > Section 4.2, step 1: it seems this step should also mention > > tmSessionID > > (extract tmSessionID from securityStateReference cache) > > I don't see this. tmSessionID is in the tmStateReference cache not > in the securityStateReferenceCache. The pointer to the > tmStateReference cache is passed to the Transport Model which will > then extract the tmSessionID and check that a Response is going out > over the session that the Request came in on (secshell 5.2 1.). Hmm, I think you're right. (I was confused about which part was checking the tmSessionID.) Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Dec 11 12:56:19 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4CF13A6987; Thu, 11 Dec 2008 12:56:19 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828223A6987 for ; Thu, 11 Dec 2008 12:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J07XK0g89CTi for ; Thu, 11 Dec 2008 12:56:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4946C3A67BD for ; Thu, 11 Dec 2008 12:56:17 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10A22C0056; Thu, 11 Dec 2008 21:56:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IKFGTpa8sMNa; Thu, 11 Dec 2008 21:56:05 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05C4FC0118; Thu, 11 Dec 2008 21:56:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3B1948ADA2A; Thu, 11 Dec 2008 21:56:04 +0100 (CET) Date: Thu, 11 Dec 2008 21:56:04 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20081211205604.GA28609@elstar.local> Mail-Followup-To: David Harrington , "'tom.petch'" , 'Wes Hardaker' , isms@ietf.org References: <012d01c95957$b1516c60$0601a8c0@allison> <02c101c95963$5c5553a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <02c101c95963$5c5553a0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] wg last call on isms document set - tsm b X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Mon, Dec 08, 2008 at 01:32:43PM -0500, David Harrington wrote: > 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 ...) 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 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms