From nea-bounces@ietf.org Fri Jan 9 16:13:13 2009 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB40F3A6AF1; Fri, 9 Jan 2009 16:13:13 -0800 (PST) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 792283A6AF1 for ; Fri, 9 Jan 2009 16:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 wvT1GOQ9x0bw for ; Fri, 9 Jan 2009 16:13:11 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 6A4623A6A56 for ; Fri, 9 Jan 2009 16:13:10 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSWfoBQsDlMxVMxZ8V8MDh5/rZYy6dyHk@postini.com; Fri, 09 Jan 2009 16:12:58 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Fri, 9 Jan 2009 16:12:20 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 16:12:19 -0800 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 16:12:19 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 9 Jan 2009 19:12:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jan 2009 19:12:18 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed PB-TNC state machine changes Thread-Index: AclypcB2Q+y69IjkRMiGpE8j308WeA== From: Stephen Hanna To: X-OriginalArrivalTime: 10 Jan 2009 00:12:19.0111 (UTC) FILETIME=[19EA6370:01C972B8] Subject: [Nea] Proposed PB-TNC state machine changes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org At IETF 73, I proposed that we change the PB-TNC state machine to eliminate a problem. I would like to verify that we have WG consensus for the solution that I proposed. I think we had consensus in the room but consensus on the mailing list is what matters. Therefore, I have described the problem and my proposed solution in this email. Please review and comment on this. Whatever your opinion, please respond to this email with an expression of your opinion within two weeks (by 5 PM PST on Friday, January 23). At that time, I will declare consensus if we have it. The problem is more easily explained with the aid of some diagrams. I suggest that you review the slides on this topic that I used at IETF 73. They are slides 30-44 in the slide deck available at http://www.ietf.org/proceedings/08nov/slides/nea-0/nea-0.htm The title of the first relevant slide is "PB-TNC State Machine". In essence, the problem is that with the state machine in draft-ietf-nea-pb-tnc-02.txt, it is possible for the PBC and PBS to get stuck in different states, losing synchronization. Say that the PBC sends CRETRY. Who should send the next message? There's no guidance. The PBS and PBC might both send the next message and then they will each believe that the message they receive from the other is a response to the message they sent. It's a bad and messy situation. The easy solutions don't work either, as described in the slides. At the meeting, I proposed a solution to the problem. That was to alter the state machine to this one: CLOSE +--------------------------------------+ | | +---------+ CRETRY +---------+ CLOSE | CDATA | Server |<---------| Decided |-----------+ | +------------>| Working |--------->| |--------+ | | | +---------+ RESULT +---------+ SASYNC | | | | ^ | | | |CASYNC | v v | | | | +---------------|-----------+ | ======= ======== | | +--------------+ | SASYNC v v " End " " Init " CDATA or| | CASYNC | | +---------+ ======= ======== CRETRY | |SDATA or v v | Server | ^ ^ | | | v SRETRY +---------+ | Request | | | | | SDATA +---------+ | Client | +---------+ | | | +--------->| Client |<---| Request | | ^ | | | | Working | SOK+---------+ | | | | | +---------+ ^ ^ | | | | | | | | CASYNC | | CASYNC | | | | | | | +----------+ +--------+ | | | | | | | | | | | +------------------------------+ | | | | SASYNC | | | +-----------------------------------------+ | | CLOSE | | CLOSE | +-----------------------------------------------------------+ This revised state machine adds several states to make sure that the client and server always agree on whose turn it is to send data after a CASYNC or SASYNC is sent. The main concern raised at IETF 73 was that this complicates the state machine, adding two new states and one new PB-TNC message type. That's true. However, I have wracked my brain for a simpler solution that works and I haven't found one. If someone else has a simpler solution, please speak up! If not, I think we'll need to proceed with this one. It's not bad. It's fairly simple, really. It just adds a bit more complexity and that's never a good thing. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Jan 9 18:43:56 2009 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B5C3A6B25; Fri, 9 Jan 2009 18:43:56 -0800 (PST) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505013A6930 for ; Fri, 9 Jan 2009 18:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 j657drrlwplQ for ; Fri, 9 Jan 2009 18:43:47 -0800 (PST) Received: from SCES1.sc.nevisnetworks.com (unknown [216.27.189.242]) by core3.amsl.com (Postfix) with ESMTP id 886F23A6B25 for ; Fri, 9 Jan 2009 18:43:47 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 9 Jan 2009 18:38:25 -0800 Message-ID: <126EBB1F0092E14B9E595D03263235AA021AE85F@SCES1.sc.nevisnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Last call for "due diligence" attributes for PA-TNC basespecification Thread-Index: AclqujePeSuWDXXcSlea8SxP7FW5ZAH/4kCQ References: From: "Joseph Tardo" To: "Paul Sangster" , "NEA" Cc: Paul Hoffman Subject: Re: [Nea] Last call for "due diligence" attributes for PA-TNC basespecification X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0579418839==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0579418839== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C972CC.8355E390" This is a multi-part message in MIME format. ------_=_NextPart_001_01C972CC.8355E390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, =20 I have given this a lot of thought both from do-the-right-thing standards and vendor perspectives and have concluded that missing Joel-suggested attribute types should be considered for inclusion, for the following reasons: =20 1. If they are used in one or more existing products as Joel found, then these products must have found them necessary. In particular, file system and registry parameters are necessary (but, alas, not sufficient) to accommodate arbitrary user-defined policies using 'commodity' clients and verifiers. Frankly I would also like to see the running process table in there as well. =20 2. The proposed set of attributes clearly leans both in semantics and terminology towards a specific product's requirements as apparent justification for their inclusion. While I have no problem with this in principle, its corollary is that adding 'genericized' attribute types used by other products should be equally justified. My example is the attributes that drill down on firewall ports - this is rather endpoint enforcement specific. Applying this rationale, shouldn't some of these attribute types also be more appropriately registered in a subsequent specification? =20 3. While everything certainly can't be anticipated, my preference would be to include a few more known types that will either forestall proliferation of subsequent specifications whose only purpose is to add numbers to the registry - should there be a WG to host such drafts - or, more likely, non-interoperable but redundant vendor-specific code points. =20 In other words, not including a few additional types seems counter productive to NEA goals to me. =20 By the way, the link to the slides is http://www.ietf.org/proceedings/08nov/slides/nea-0/nea-0.htm. Also, I realize I may have missed the deadline by a few hours, but hope these points will be considered anyway. =20 Thanks, --Joe =20 ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Paul Sangster Sent: Tuesday, December 30, 2008 12:07 PM To: NEA Cc: Paul Hoffman Subject: [Nea] Last call for "due diligence" attributes for PA-TNC basespecification =20 The PA-TNC editors are making a last call for PA-TNC "due diligence" attributes that you would like to advocate as being required to be included in the PA-TNC base specification before starting the WGLC approval process. At IETF 73, we discussed that separate specifications could be created in the future to define additional PA-TNC standard attributes as required so the base specification should do a best effort to define the initial standard set. However we wanted to take a final WG check to see if any of the "due diligence" attributes identified by Joel Snyder are important to include in the initial PA-TNC base spec before it progresses. If you feel strongly that one or more due diligence attributes should be included in the base specification (and not in a future attribute specification) please state your reasoning to the WG alias by Friday Jan 9, 2009 at 5PM PST. =20 BACKGROUND =20 During the NEA WG meeting at IETF 73, we discussed the list of "due diligence" attributes gathered by Joel Snyder. As you will recall this attribute investigation was done to try to identify additional PA attributes that were commonly used in today's NAC products that were not currently captured by the PA-TNC specification. =20 Joel performed the analysis by looking at the policies supported by prevalent NAC products and inferred the attributes required to support these policies using the NEA protocols. In order to not be tainted by the current specification, Joel did not attempt to filter out attributes already in the PA-TNC specification. The editor team reviewed the reported attributes and presented a categorized list of attributes listing those believed to be already covered and some rationale for why those not covered were not required in the base specification at this time. See the presentation categorization at: http://www3.ietf.org/proceedings/08nov/slides/nea-0.ppt on slides 19 - 27. This prompted some discussion at the meeting that we would like to resolve on the WG alias. =20 Please review the IETF 73 slides and if necessary listen to the audio recording and read Joel's original e-mail. Notify the WG alias if you feel strongly that any additional of these attributes are required in the PA-TNC base specification before it progresses. =20 =20 Thanks, =20 PA-TNC Editors =20 =20 ------_=_NextPart_001_01C972CC.8355E390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Paul,

 

I have given this a lot of thought = both from do-the-right-thing standards and vendor perspectives and have = concluded that missing Joel-suggested attribute types should be considered for = inclusion, for the following reasons:

 

1. If they are used in one or more = existing products as Joel found, then these products must have found them = necessary. In particular, file system and registry parameters are necessary (but, = alas, not sufficient) to accommodate arbitrary user-defined policies using = ‘commodity’ clients and verifiers. Frankly I would also like to see the running = process table in there as well.

 

2. The proposed set of attributes = clearly leans both in semantics and terminology towards a specific product’s requirements as apparent justification for their inclusion. While I have = no problem with this in principle, its corollary is that adding = ‘genericized’ attribute types used by other products should be equally justified. My = example is the attributes that drill down on firewall ports – this is rather endpoint enforcement specific. Applying this rationale, shouldn’t = some of these attribute types also be more appropriately registered in a = subsequent specification?

 

3. While everything certainly = can’t be anticipated, my preference would be to include a few more known types = that will either forestall proliferation of subsequent specifications whose = only purpose is to add numbers to the registry – should there be a WG = to host such drafts – or, more likely, non-interoperable but redundant = vendor-specific code points.

 

In other words, not including a few additional types seems counter productive to NEA goals to = me.

 

By the way, the link to the slides = is htt= p://www.ietf.org/proceedings/08nov/slides/nea-0/nea-0.htm. Also, I realize I may have missed the deadline by a few hours, but hope = these points will be considered anyway.

 

Thanks,

=

--Joe

 

From: = nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On = Behalf Of Paul Sangster
Sent: Tuesday, December = 30, 2008 12:07 PM
To: NEA
Cc: Paul Hoffman
Subject: [Nea] Last call = for "due diligence" attributes for PA-TNC = basespecification

 

The PA-TNC editors are making a last call for = PA-TNC "due diligence" attributes that you would like to advocate as = being required to be included in the PA-TNC base specification before starting = the WGLC approval process.  At IETF 73, we discussed that separate specifications could be created in the future to define additional = PA-TNC standard attributes as required so the base specification should do a best effort = to define the initial standard set.  However we wanted to take a final = WG check to see if any of the "due diligence" attributes = identified by Joel Snyder are important to include in the initial PA-TNC base spec = before it progresses.   If you feel strongly that one or more due = diligence attributes should be included in the base specification (and not in a = future attribute specification) please state your reasoning to the WG alias by = Friday Jan 9, 2009 at 5PM PST.

 

BACKGROUND

 

During the NEA WG meeting at IETF 73, we discussed = the list of "due diligence" attributes gathered by Joel Snyder.  = As you will recall this attribute investigation was done to try to identify = additional PA attributes that were commonly used in today's NAC products that were = not currently captured by the PA-TNC = specification.

 

Joel performed the analysis by looking at the = policies supported by prevalent NAC products and inferred the attributes required = to support these policies using the NEA protocols.  In order to not be tainted by the current specification, Joel did not attempt to filter out attributes already in the PA-TNC specification.  The editor team = reviewed the reported attributes and presented a categorized list of attributes = listing those believed to be already covered and some rationale for why those = not covered were not required in the base specification at this time.  = See the presentation categorization at: http://w= ww3.ietf.org/proceedings/08nov/slides/nea-0.ppt on slides 19 - 27.  This prompted some discussion at the meeting that = we would like to resolve on the WG alias.

 

Please review the IETF 73 slides and if = necessary listen to the audio recording and read Joel's original e-mail. Notify = the WG alias if you feel strongly that any additional of these attributes = are required in the PA-TNC base specification before it progresses.  =

 

Thanks,

 

PA-TNC Editors

 

 

------_=_NextPart_001_01C972CC.8355E390-- --===============0579418839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea --===============0579418839==-- From nea-bounces@ietf.org Mon Jan 12 14:51:43 2009 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF7E3A67E4; Mon, 12 Jan 2009 14:51:43 -0800 (PST) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965C33A67E4 for ; Mon, 12 Jan 2009 14:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 k4vaDhaz4EFn for ; Mon, 12 Jan 2009 14:51:41 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id A85553A67C0 for ; Mon, 12 Jan 2009 14:51:41 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSWvJZzJIV0B5aKAwaDlC0Ae21sU4A4Al@postini.com; Mon, 12 Jan 2009 14:51:27 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Mon, 12 Jan 2009 14:49:07 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Jan 2009 14:49:07 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Jan 2009 14:49:07 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jan 2009 17:49:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jan 2009 17:49:05 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Consensus check on NEA IANA Considerations Thread-Index: AclnnwtbwrnJ9GwaQ4u7PFDXMSZiBgNPcXQg References: From: Stephen Hanna To: X-OriginalArrivalTime: 12 Jan 2009 22:49:06.0395 (UTC) FILETIME=[F943A2B0:01C97507] Subject: Re: [Nea] Consensus check on NEA IANA Considerations X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org I have not seen any email responses to this note. Since there was consensus at the NEA F2F meeting at IETF 73 and no objections have been raised here on the email list, I judge that there is consensus in favor of the proposal below. This proposal will be reflected in the next versions of the PA-TNC and PB-TNC specifications. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On > Behalf Of Stephen Hanna > Sent: Friday, December 26, 2008 4:15 PM > To: nea@ietf.org > Subject: [Nea] Consensus check on NEA IANA Considerations > > At the NEA WG meeting at IETF 73, there was a > discussion about IANA Considerations for PA-TNC > and PB-TNC. At the meeting, there was consensus > in the room for this proposal: > > ---------- > > For all IANA registries defined in PA-TNC and > PB-TNC, the following requirements must be met > to add an entry to the registry: > > - Expert Review > - Specification Publically Available (RFC or other > IANA archived document) > - Specification must be clear and ensure interoperability > - Must be judged useful and not harmful to the Internet > > Values with PEN <> 0 could also be registered. The same > requirements would apply except that the "useful and not > harmful" requirement would be waived. > > ---------- > > I want to check consensus on our email list for this > proposal. Please send email to the nea@ietf.org list > indicating whether you support or oppose the proposal. > > In light of the holiday season, this consensus check > will end in two weeks, at 5 PM EST (2200 GMT) on Friday, > January 9. > > Thanks, > > Steve > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jan 12 14:52:15 2009 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D09EE3A695B; Mon, 12 Jan 2009 14:52:15 -0800 (PST) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46F73A6946 for ; Mon, 12 Jan 2009 14:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 BI6-cLxuxgAf for ; Mon, 12 Jan 2009 14:52:14 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id CF9F23A6903 for ; Mon, 12 Jan 2009 14:52:13 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSWvJjw4aC5Ng3H/DzpJTGoLK7QAYkNU9@postini.com; Mon, 12 Jan 2009 14:52:00 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Mon, 12 Jan 2009 14:50:17 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Jan 2009 14:50:17 -0800 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Jan 2009 14:50:17 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 12 Jan 2009 17:50:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jan 2009 17:50:14 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Consensus check on Assertion Attributes Thread-Index: AclnnwwXrBAv/rj8TZqqusX8FQE/8ANPbwTA References: From: Stephen Hanna To: X-OriginalArrivalTime: 12 Jan 2009 22:50:16.0628 (UTC) FILETIME=[23205740:01C97508] Subject: Re: [Nea] Consensus check on Assertion Attributes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org I have seen one email in response to this consensus check (sent by Beza on December 30). This email supported the proposal below. While this is not an overwhelming show of support for the proposal, when I also consider all the people at the NEA F2F meeting at IETF 73 who hummed in favor of this proposal the WG consensus seems to be clearly in favor of the proposal to decouple assertion attributes from the base protocol specifications. This decision will not require any changes to the current PA-TNC and PB-TNC specifications. Instead, I would like to invite people to submit separate proposals for assertion attributes, preferably in Internet Draft format. The NEA WG will consider these for possible future adoption as WG drafts. Even if they are not adopted as WG drafts, they can proceed as independent submissions. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On > Behalf Of Stephen Hanna > Sent: Friday, December 26, 2008 4:15 PM > To: nea@ietf.org > Subject: [Nea] Consensus check on Assertion Attributes > > At the NEA WG meeting at IETF 73, there was a > discussion about assertion attributes. I want > to check consensus on our email list for the > results of that discussion. > > First, some background. RFC 5209 defines assertion > attributes as "attributes that include reusable > information about the success of a prior > assessment of the endpoint". RFC 5209 does not > contain any requirement that PA-TNC and PB-TNC > support assertion attributes but it would be > good to support these attributes since they can > be used to skip a full assessment when one has > recently been done. The current PA-TNC and PB-TNC > specs do not include explicit support for assertion > attributes but they are extensible enough that > support for these attributes could be added later. > > At the end of the NEA WG discussion on this topic > at IETF 73, there was consensus in the room to not > hold up the current protocol documents to include > assertion attributes. Rather, support for assertion > attributes would be specified in a separate document. > This will allow for proposals to be solicited and > properly considered without further delaying the > base protocol specifications, which are already > behind schedule. > > So please send email to the nea@ietf.org list > indicating whether you support or oppose the > proposal to decouple assertion attributes from > the base protocol specifications. > > In light of the holiday season, this consensus > check will end in two weeks, at 5 PM EST (2200 GMT) > on Friday, January 9. > > Thanks, > > Steve > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Jan 16 13:19:06 2009 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC1FC3A6AF1; Fri, 16 Jan 2009 13:19:06 -0800 (PST) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691373A6A55 for ; Fri, 16 Jan 2009 13:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.391 X-Spam-Level: X-Spam-Status: No, score=-5.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001, 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 SuYxlyNjJ05f for ; Fri, 16 Jan 2009 13:19:04 -0800 (PST) Received: from extu-mxob-1.symantec.com (extu-mxob-1.symantec.com [216.10.194.28]) by core3.amsl.com (Postfix) with ESMTP id 8C9593A6964 for ; Fri, 16 Jan 2009 13:19:04 -0800 (PST) Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) by extu-mxob-1.symantec.com (8.14.1/8.14.1) with ESMTP id n0GLIm7E015204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Jan 2009 13:18:48 -0800 Received: from reserved-155-64-230-18.ges.symantec.com ([155.64.230.18] helo=TUS1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1LNw5Y-0003We-PH for nea@ietf.org; Fri, 16 Jan 2009 13:18:48 -0800 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jan 2009 14:18:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Jan 2009 14:18:46 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Eval Against NEA Requirements Thread-Index: Acl4IASdRhtIJvOFQg64KB71nBMRlQ== From: "Paul Sangster" To: "NEA" X-OriginalArrivalTime: 16 Jan 2009 21:18:48.0527 (UTC) FILETIME=[059D95F0:01C97820] Subject: [Nea] Eval Against NEA Requirements X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0768615117==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0768615117== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97820.058DA914" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97820.058DA914 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The editors have been working on the WG discussed updates to the next revision of PA-TNC and PB-TNC specs. One question that was raised was whether the Evaluation Against NEA Requirements sections of the I-Ds is still required. These section were included in the original personal submission I-Ds as part of the author's asserting that the PA-TNC and PB-TNC protocols met the requirements of RFC 5209. These sections seem to have some value for historical purposes and to show the NEA WG considered RFC 5209 during the selection process, but do we still need this text in our eventual RFCs for the protocols? =20 The question we would like the WG to answer is: =20 What should we do with the Evaluation Against NEA Requirements text (section 5) in PA-TNC and PB-TNC? =20 1) Remove it 2) Leave it as is 3) Move it to an appendix =20 Please respond to this question by 5PM PST on Jan 23rd so the editors can make the desired change. =20 =20 Thanks, =20 The PA and PB Editors =20 =20 ------_=_NextPart_001_01C97820.058DA914 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The = editors have=20 been working on the WG discussed updates to the next revision of PA-TNC = and=20 PB-TNC specs.  One question that was raised was whether the = Evaluation=20 Against NEA Requirements sections of the I-Ds is still required.  = These=20 section were included in the original personal submission I-Ds as part = of the=20 author's asserting that the PA-TNC and PB-TNC protocols met the = requirements of=20 RFC 5209.  These sections seem to have some value for = historical=20 purposes and to show the NEA WG considered RFC 5209 during the selection = process, but do we still need this text in our eventual RFCs for = the=20 protocols?
 
The = question we=20 would like the WG to answer is:
 
What = should we do=20 with the Evaluation Against NEA Requirements text (section 5) in PA-TNC = and=20 PB-TNC?
 
1) = Remove=20 it
2) = Leave it as=20 is
3) = Move it to=20 an appendix
 
Please = respond to=20 this question by 5PM PST on Jan 23rd so the editors can make the desired = change. 
 
Thanks,
 
The PA = and PB=20 Editors
 
 
------_=_NextPart_001_01C97820.058DA914-- --===============0768615117== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea --===============0768615117==-- From nea-bounces@ietf.org Fri Jan 16 14:14:54 2009 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BAAA3A6AF1; Fri, 16 Jan 2009 14:14:54 -0800 (PST) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0920A3A6AF1 for ; Fri, 16 Jan 2009 14:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GLApU9PBpTEf for ; Fri, 16 Jan 2009 14:14:42 -0800 (PST) Received: from extu-mxob-1.symantec.com (extu-mxob-1.symantec.com [216.10.194.28]) by core3.amsl.com (Postfix) with ESMTP id CC5CF3A695E for ; Fri, 16 Jan 2009 14:14:41 -0800 (PST) Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) by extu-mxob-1.symantec.com (8.14.1/8.14.1) with ESMTP id n0GMEPqN012456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 14:14:25 -0800 Received: from reserved-155-64-230-18.ges.symantec.com ([155.64.230.18] helo=TUS1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1LNwxN-0005pm-Ni; Fri, 16 Jan 2009 14:14:25 -0800 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jan 2009 15:14:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Jan 2009 15:14:23 -0700 Message-ID: In-Reply-To: <126EBB1F0092E14B9E595D03263235AA021AE85F@SCES1.sc.nevisnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Last call for "due diligence" attributes for PA-TNC basespecification Thread-Index: AclqujePeSuWDXXcSlea8SxP7FW5ZAH/4kCQAVnF30A= References: <126EBB1F0092E14B9E595D03263235AA021AE85F@SCES1.sc.nevisnetworks.com> From: "Paul Sangster" To: "Joseph Tardo" , "NEA" X-OriginalArrivalTime: 16 Jan 2009 22:14:25.0443 (UTC) FILETIME=[CA928F30:01C97827] Cc: Paul Hoffman Subject: Re: [Nea] Last call for "due diligence" attributes for PA-TNC basespecification X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1275794430==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1275794430== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97827.CA6EF296" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97827.CA6EF296 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joe, =20 Thanks for your response, the editors discussed your feedback and our thoughts are below... ________________________________ From: Joseph Tardo [mailto:joseph.tardo@nevisnetworks.com]=20 Sent: Friday, January 09, 2009 6:38 PM To: Paul Sangster; NEA Cc: Paul Hoffman Subject: RE: [Nea] Last call for "due diligence" attributes for PA-TNC basespecification =09 =09 Paul, =20 I have given this a lot of thought both from do-the-right-thing standards and vendor perspectives and have concluded that missing Joel-suggested attribute types should be considered for inclusion, for the following reasons: =20 1. If they are used in one or more existing products as Joel found, then these products must have found them necessary. In particular, file system and registry parameters are necessary (but, alas, not sufficient) to accommodate arbitrary user-defined policies using 'commodity' clients and verifiers. Frankly I would also like to see the running process table in there as well. =20 [PS] The attributes mentioned were specifically discussed in Minneapolis and while they may exist in a number of commercial implementations could be considered a privacy concern in the IETF as they allow the NEA server to ask very focused questions about any portion of the endpoint's operational state - not just assessing the readiness of security components on the endpoint. Such questions were discussed during the formation of the WG and were considered outside of the charter due to privacy concerns. Instead it was suggested that we take the base protocol specifications through the approval process and additional attributes (or other NEA code points managed by our IANA registry process) could be added using our agreed upon lightweight approval process. See Steve's consensus check e-mail from 12/26/08 which states: =20 "For all IANA registries defined in PA-TNC and PB-TNC, the following requirements must be met to add an entry to the registry: - Expert Review - Specification Publically Available (RFC or other IANA archived document) - Specification must be clear and ensure interoperability - Must be judged useful and not harmful to the internet" =20 2. The proposed set of attributes clearly leans both in semantics and terminology towards a specific product's requirements as apparent justification for their inclusion. While I have no problem with this in principle, its corollary is that adding 'genericized' attribute types used by other products should be equally justified. My example is the attributes that drill down on firewall ports - this is rather endpoint enforcement specific. Applying this rationale, shouldn't some of these attribute types also be more appropriately registered in a subsequent specification? =20 [PS] I don't believe that the specification includes specific products requirements so I'm not sure if you mean "specific technology requirements". In other words, we tried to avoid including attributes specific to a single (or very small number of) vendor implementations but tried to represent common security oriented technologies that may be found on the endpoint. The firewall ports are a good example of an endpoint security technology that could be present and included in an assessment. Many vendors offer endpoint firewall products and should be able to represent their simple filtering rules using this attribute so its not (vendor) product specific. =20 [PS] The attributes included on Product Specific slide were considered to be not generic enough (e.g. Google desktop search installed). Note that these could be added later using the IANA registry process if desired and appropriate. The expert group could help decide whether the attribute should be standardized as an IETF (Vendor ID =3D IETF (0)) or vendor specific well known value.=20 =20 3. While everything certainly can't be anticipated, my preference would be to include a few more known types that will either forestall proliferation of subsequent specifications whose only purpose is to add numbers to the registry - should there be a WG to host such drafts - or, more likely, non-interoperable but redundant vendor-specific code points. =20 [PS] I agree that we won't be able to anticipate everything that will be needed over the long term as the list will constantly be growing. We tried to put in place with the IANA registry a lightweight way to register new code points. The registry will handle hosting the drafts and the expert group reviewing them. Note that these specifications will need to document the attribute contents and semantics to enable interoperability so its more then just adding a number. =20 In other words, not including a few additional types seems counter productive to NEA goals to me. =20 By the way, the link to the slides is http://www.ietf.org/proceedings/08nov/slides/nea-0/nea-0.htm. Also, I realize I may have missed the deadline by a few hours, but hope these points will be considered anyway. =20 [PS] Thanks.=20 =20 Thanks, --Joe =20 =09 ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Paul Sangster Sent: Tuesday, December 30, 2008 12:07 PM To: NEA Cc: Paul Hoffman Subject: [Nea] Last call for "due diligence" attributes for PA-TNC basespecification =20 The PA-TNC editors are making a last call for PA-TNC "due diligence" attributes that you would like to advocate as being required to be included in the PA-TNC base specification before starting the WGLC approval process. At IETF 73, we discussed that separate specifications could be created in the future to define additional PA-TNC standard attributes as required so the base specification should do a best effort to define the initial standard set. However we wanted to take a final WG check to see if any of the "due diligence" attributes identified by Joel Snyder are important to include in the initial PA-TNC base spec before it progresses. If you feel strongly that one or more due diligence attributes should be included in the base specification (and not in a future attribute specification) please state your reasoning to the WG alias by Friday Jan 9, 2009 at 5PM PST. =20 BACKGROUND =20 During the NEA WG meeting at IETF 73, we discussed the list of "due diligence" attributes gathered by Joel Snyder. As you will recall this attribute investigation was done to try to identify additional PA attributes that were commonly used in today's NAC products that were not currently captured by the PA-TNC specification. =20 Joel performed the analysis by looking at the policies supported by prevalent NAC products and inferred the attributes required to support these policies using the NEA protocols. In order to not be tainted by the current specification, Joel did not attempt to filter out attributes already in the PA-TNC specification. The editor team reviewed the reported attributes and presented a categorized list of attributes listing those believed to be already covered and some rationale for why those not covered were not required in the base specification at this time. See the presentation categorization at: http://www3.ietf.org/proceedings/08nov/slides/nea-0.ppt on slides 19 - 27. This prompted some discussion at the meeting that we would like to resolve on the WG alias. =20 Please review the IETF 73 slides and if necessary listen to the audio recording and read Joel's original e-mail. Notify the WG alias if you feel strongly that any additional of these attributes are required in the PA-TNC base specification before it progresses. =20 =20 Thanks, =20 PA-TNC Editors =20 =20 ------_=_NextPart_001_01C97827.CA6EF296 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Joe,
 
Thanks for your response, the editors discussed = your=20 feedback and our thoughts are below...

From: Joseph Tardo=20 [mailto:joseph.tardo@nevisnetworks.com]
Sent: Friday, = January 09,=20 2009 6:38 PM
To: Paul Sangster; NEA
Cc: Paul=20 Hoffman
Subject: RE: [Nea] Last call for "due diligence" = attributes=20 for PA-TNC basespecification

Paul,

 

I have = given this a=20 lot of thought both from do-the-right-thing standards and vendor = perspectives=20 and have concluded that missing Joel-suggested attribute types should = be=20 considered for inclusion, for the following=20 reasons:

 

1. If they = are used=20 in one or more existing products as Joel found, then these products = must have=20 found them necessary. In particular, file system and registry = parameters are=20 necessary (but, alas, not sufficient) to accommodate arbitrary = user-defined=20 policies using ‘commodity’ clients and verifiers. Frankly = I would also like to=20 see the running process table in there as well.
 
[PS] The = attributes=20 mentioned were specifically discussed in Minneapolis and = while they=20 may exist in a number of commercial implementations could be = considered a=20 privacy concern in the IETF as they allow the NEA server to ask very = focused=20 questions about any portion of the endpoint's operational state - not = just=20 assessing the readiness of security components on the endpoint.  = Such=20 questions were discussed during the formation of the WG and were = considered=20 outside of the charter due to privacy concerns. =20 Instead it was = suggested that we=20 take the base protocol specifications through the approval process and = additional attributes (or other NEA code points managed by our IANA = registry=20 process) could be added using our agreed upon lightweight approval=20 process.  See Steve's consensus check e-mail from 12/26/08 which=20 states:

 

"For all IANA registries defined in PA-TNC and = PB-TNC, the following requirements must be met = to add an entry to the=20 registry:

- = Expert=20 Review

- = Specification=20 Publically Available (RFC or other IANA archived=20 document)

- = Specification=20 must be clear and ensure = interoperability

- = Must be judged=20 useful and not harmful to the = internet"

 

2. The = proposed set=20 of attributes clearly leans both in semantics and terminology towards = a=20 specific product’s requirements as apparent justification for = their inclusion.=20 While I have no problem with this in principle, its corollary is that = adding=20 ‘genericized’ attribute types used by other products = should be equally=20 justified. My example is the attributes that drill down on firewall = ports –=20 this is rather endpoint enforcement specific. Applying this rationale, = shouldn’t some of these attribute types also be more = appropriately registered=20 in a subsequent specification?
 
[PS] I don't believe that the specification = includes=20 specific products requirements so I'm not sure if you mean "specific=20 technology requirements".  In other words, we tried to avoid = including=20 attributes specific to a single (or very small number of) vendor=20 implementations but tried to represent common security oriented = technologies=20 that may be found on the endpoint. The firewall ports are a good example = of an=20 endpoint security technology that could be present and included in an=20 assessment.  Many vendors offer endpoint firewall products and = should be=20 able to represent their simple filtering rules using this attribute so = its not=20 (vendor) product specific.

 

[PS] The attributes = included on=20 Product Specific slide were considered to be not generic enough (e.g. = Google=20 desktop search installed).  Note that these could be added = later=20 using the IANA registry process if desired and appropriate.  The = expert=20 group could help decide whether the attribute should be standardized = as an=20 IETF (Vendor ID =3D IETF (0)) or vendor specific well=20 known value. 

 

3. While = everything=20 certainly can’t be anticipated, my preference would be to = include a few more=20 known types that will either forestall proliferation of subsequent=20 specifications whose only purpose is to add numbers to the registry = – should=20 there be a WG to host such drafts – or, more likely, = non-interoperable but=20 redundant vendor-specific code points.
 
[PS] I agree that we won't be able to = anticipate=20 everything that will be needed over the long term as the list will = constantly=20 be growing.  We tried to put in place with the IANA registry a=20 lightweight way to register new code points.  The registry will = handle=20 hosting the drafts and the expert group reviewing them.  Note = that these=20 specifications will need to document the attribute contents and = semantics to=20 enable interoperability so its more then just adding a=20 number.

 

In other = words, not=20 including a few additional types seems counter productive to NEA goals = to=20 me.
 
By the way, = the link=20 to the slides is htt= p://www.ietf.org/proceedings/08nov/slides/nea-0/nea-0.htm.=20 Also, I realize I may have missed the deadline by a few hours, but = hope these=20 points will be considered anyway.
 
[PS] Thanks.<= FONT=20 color=3Dnavy> <= /P>

 

Thanks,

--Joe

 

From:=20 nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Paul = Sangster
Sent: Tuesday, December 30, = 2008 12:07=20 PM
To: = NEA
Cc: Paul Hoffman
Subject: [Nea] Last call for = "due=20 diligence" attributes for PA-TNC=20 basespecification

 

The PA-TNC editors are = making a=20 last call for PA-TNC "due diligence" attributes that you would = like to=20 advocate as being required to be included in the PA-TNC base = specification=20 before starting the WGLC approval process.  At IETF 73, we = discussed that=20 separate specifications could be created in the future to define = additional=20 PA-TNC standard attributes as required so the base specification = should do a=20 best effort to define the initial standard set.  However we = wanted to=20 take a final WG check to see if any of the "due diligence" attributes=20 identified by Joel Snyder are important to include in the initial = PA-TNC base=20 spec before it progresses.   If you feel strongly that one = or more=20 due diligence attributes should be included in the base specification = (and not=20 in a future attribute specification) please state your reasoning to = the WG=20 alias by Friday Jan 9, 2009 at 5PM = PST.

 

BACKGROUND

 

During the NEA WG = meeting at IETF=20 73, we discussed the list of "due diligence" attributes gathered by = Joel=20 Snyder.  As you will recall this attribute investigation was done = to try=20 to identify additional PA attributes that were commonly used in = today's NAC=20 products that were not currently captured by the PA-TNC=20 specification.

 

Joel performed the = analysis=20 by looking at the policies supported by prevalent NAC products and = inferred=20 the attributes required to support these policies using the NEA=20 protocols.  In order to not be tainted by the current = specification, Joel=20 did not attempt to filter out attributes already in the PA-TNC=20 specification.  The editor team reviewed the reported attributes = and=20 presented a categorized list of attributes listing those believed to = be=20 already covered and some rationale for why those not covered were not = required=20 in the base specification at this time.  See the presentation=20 categorization at: http://w= ww3.ietf.org/proceedings/08nov/slides/nea-0.ppt on=20 slides 19 - 27.  This prompted some discussion at the meeting = that we=20 would like to resolve on the WG = alias.

 

Please review the IETF=20 73 slides and if necessary listen to the audio recording and read = Joel's=20 original e-mail. Notify the WG alias if you feel strongly that = any=20 additional of these attributes are required in the PA-TNC base = specification=20 before it progresses. 

 

Thanks,

 

PA-TNC=20 Editors

 

 

= ------_=_NextPart_001_01C97827.CA6EF296-- --===============1275794430== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea --===============1275794430==-- From nea-bounces@ietf.org Fri Jan 16 17:56:43 2009 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5186828C119; Fri, 16 Jan 2009 17:56:43 -0800 (PST) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC16C3A696D for ; Fri, 16 Jan 2009 15:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 lmGB3kO3afBA for ; Fri, 16 Jan 2009 15:12:25 -0800 (PST) Received: from fmailhost04.isp.att.net (fmailhost04.isp.att.net [204.127.217.104]) by core3.amsl.com (Postfix) with ESMTP id 161693A694F for ; Fri, 16 Jan 2009 15:12:25 -0800 (PST) Received: from nevisl0015 (63-166-164-109.volcano.net[63.166.164.109]) by isp.att.net (frfwmhc04) with SMTP id <20090116231208H04007qghse>; Fri, 16 Jan 2009 23:12:09 +0000 X-Originating-IP: [63.166.164.109] Message-ID: From: "Joseph Tardo" To: "Paul Sangster" , "NEA" References: Date: Fri, 16 Jan 2009 15:12:06 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailman-Approved-At: Fri, 16 Jan 2009 17:56:41 -0800 Subject: Re: [Nea] Eval Against NEA Requirements X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1096264399==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1096264399== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C977EC.CB7F3AF0" This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C977EC.CB7F3AF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would be OK with moving it to an annex, preferably before the use = cases. --Joe ----- Original Message -----=20 From: Paul Sangster=20 To: NEA=20 Sent: Friday, January 16, 2009 1:18 PM Subject: [Nea] Eval Against NEA Requirements The editors have been working on the WG discussed updates to the next = revision of PA-TNC and PB-TNC specs. One question that was raised was = whether the Evaluation Against NEA Requirements sections of the I-Ds is = still required. These section were included in the original personal = submission I-Ds as part of the author's asserting that the PA-TNC and = PB-TNC protocols met the requirements of RFC 5209. These sections seem = to have some value for historical purposes and to show the NEA WG = considered RFC 5209 during the selection process, but do we still need = this text in our eventual RFCs for the protocols? The question we would like the WG to answer is: What should we do with the Evaluation Against NEA Requirements text = (section 5) in PA-TNC and PB-TNC? 1) Remove it 2) Leave it as is 3) Move it to an appendix Please respond to this question by 5PM PST on Jan 23rd so the editors = can make the desired change. =20 Thanks, The PA and PB Editors -------------------------------------------------------------------------= ----- _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea ------=_NextPart_000_0017_01C977EC.CB7F3AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I would be OK with moving it to an = annex,=20 preferably before the use cases.
 
--Joe
----- Original Message -----
From:=20 Paul Sangster
To: NEA
Sent: Friday, January 16, 2009 = 1:18=20 PM
Subject: [Nea] Eval Against NEA = Requirements

The = editors have=20 been working on the WG discussed updates to the next revision of = PA-TNC and=20 PB-TNC specs.  One question that was raised was whether the = Evaluation=20 Against NEA Requirements sections of the I-Ds is still required.  = These=20 section were included in the original personal submission I-Ds as part = of the=20 author's asserting that the PA-TNC and PB-TNC protocols met the = requirements=20 of RFC 5209.  These sections seem to have some value for = historical=20 purposes and to show the NEA WG considered RFC 5209 during the = selection=20 process, but do we still need this text in our eventual RFCs for = the=20 protocols?
 
The = question we=20 would like the WG to answer is:
 
What = should we do=20 with the Evaluation Against NEA Requirements text (section 5) in = PA-TNC and=20 PB-TNC?
 
1) = Remove=20 it
2) = Leave it as=20 is
3) = Move it to=20 an appendix
 
Please respond to=20 this question by 5PM PST on Jan 23rd so the editors can make the = desired=20 change. 
 
Thanks,
 
The = PA and PB=20 Editors
 
 

_______________________________________________
Nea mailing=20 = list
Nea@ietf.org
https://www.ietf.org/mailman/listinfo/nea
------=_NextPart_000_0017_01C977EC.CB7F3AF0-- --===============1096264399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea --===============1096264399==-- From nea-bounces@ietf.org Fri Jan 16 20:06:26 2009 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BF63A6A37; Fri, 16 Jan 2009 20:06:26 -0800 (PST) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8743D3A689D for ; Fri, 16 Jan 2009 20:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 74qIqxbivvJy for ; Fri, 16 Jan 2009 20:06:24 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id A26033A6A37 for ; Fri, 16 Jan 2009 20:06:24 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSXFZJajzDxirgB6fclFUppyTyYVNlb8n@postini.com; Fri, 16 Jan 2009 20:06:09 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Fri, 16 Jan 2009 19:57:42 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 19:57:38 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 19:57:38 -0800 Received: from antimuon.jnpr.net ([172.24.60.32]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 19:57:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Jan 2009 19:57:35 -0800 Message-ID: <1039CD74656F7B42816FE6532F32C194062544B7@antimuon.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Eval Against NEA Requirements Thread-Index: Acl4IASdRhtIJvOFQg64KB71nBMRlQAHK8QQ References: From: Lisa Lorenzin To: "NEA" X-OriginalArrivalTime: 17 Jan 2009 03:57:36.0150 (UTC) FILETIME=[BB971B60:01C97857] Subject: Re: [Nea] Eval Against NEA Requirements X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Greetings! > What should we do with the Evaluation Against NEA > Requirements text (section 5) in PA-TNC and PB-TNC? I think retaining that information does add historical value, but it's not necessarily relevant to the primary content of the spec. I'm in favor of option 3, moving it to an appendix. Regards, Lisa -- Lisa Lorenzin / 919-384-7275 / llorenzin@juniper.net Principal Solutions Architect - Security Solutions Juniper Networks / http://www.juniper.net _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jan 22 14:17:57 2009 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634FD28C0FC; Thu, 22 Jan 2009 14:17:57 -0800 (PST) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02CA3A68AF for ; Thu, 22 Jan 2009 14:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 lB2uiYszj-U1 for ; Thu, 22 Jan 2009 14:17:54 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 845DD3A6856 for ; Thu, 22 Jan 2009 14:17:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,308,1231113600"; d="scan'208";a="132453037" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 22 Jan 2009 22:17:38 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0MMHan7023214; Thu, 22 Jan 2009 14:17:36 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0MMHaRM022175; Thu, 22 Jan 2009 22:17:36 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 14:17:35 -0800 Received: from 171.69.75.173 ([171.69.75.173]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Jan 2009 22:16:52 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 22 Jan 2009 14:16:51 -0800 From: kaushik To: Stephen Hanna , Message-ID: Thread-Topic: [Nea] Proposed PB-TNC state machine changes Thread-Index: AclypcB2Q+y69IjkRMiGpE8j308WeAKOV9Z3 In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 22 Jan 2009 22:17:35.0859 (UTC) FILETIME=[3A8C3C30:01C97CDF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8037; t=1232662656; x=1233526656; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20kaushik=20 |Subject:=20Re=3A=20[Nea]=20Proposed=20PB-TNC=20state=20mac hine=20changes |Sender:=20; bh=qWODPQ0CF295cmu2bJDyW8jZL69uUHJZvy8yUgrr7tM=; b=H/v8Od/FF/k+BGxCktlnolllnBHqzV/4Yly40lUAsZ8m1+VLXQPGG5IqWw 5e+LblgPZBPPAnoM2DTZBpC415/vBX7qvZMvXR7wEyFtCw0ZdBW47RidgNFx PbxYhmcnMH; Authentication-Results: sj-dkim-2; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Nea] Proposed PB-TNC state machine changes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Hi Steve, The proposed solution addresses the synchronization issues with the PB-TNC state machine but introduces additional states and state transitions which increase the overall complexity of the state machine as you have pointed out. Here is an alternate that might be a simpler option The fundamental problem is that re-assessment can be initiated by either by the Posture Broker Client or the Posture Broker Server and the state machine on the PBS and PBC can get out of synch if the re-assessment messages are generated at the same time and cross each other in transit. We can make a simplifying assumption that we won't allow re-assessment to be triggered during an assessment, i.e. Assessments will run to completion without being interrupted. This would mean that CRETRY and SRERTY messages can only be sent from the Decided state and that CRETRY & SRETRY messages sent during an assessment, i.e. when the state is either Client Working or Server Working, will be ignored. The updated State Machine would look like this Receive CRETRY or SRETRY* SRETRY* +--+ +----------------+ | | | | v | v | +---------+ CRETRY +---------+ CDATA | Server |<---------| Decided | CLOSE +----------->| Working |--------->| |-------+ | +---------+ RESULT +---------+ | | ^ | | v | | | +---------------------->======= ======== | | CLOSE " End " " Init " CDATA| |SDATA ======= ======== | | ^ ^ | | | v | | | | SDATA +---------+ CLOSE | | | +-------->| Client |----------------------+ | | | Working | | | +---------+ | | | ^ Receive | | | | CRETRY* | | +--+ | | CLOSE | +--------------------------------------------------+ The changes from the state machine in the -02 version of the draft include - CRETRY/SRETRY can only be sent from Decided state. - CRERTY and SRETRY sent from the Decided state move the state machine to Server Working state. - CRETRY or SRETRY messages received in Server Working state are ignored - CRETRY message received in Client Working state is ignored. Let's apply this state machine to a re-assessment scenario. 1. The state machine is in the Decided state and the Posture Broker Server decides to initiate a re-assessment and sends a SRERTY and the state machine on the PBS moves to the Server Working state. 3. The Posture Broker Client may at the exact same time decide to initiate a re-assessment and send a CRETRY and that would move the state machine on the PBC to the Server Working state. 4. The PBS can receive the CRETRY from the PBC before or after it sends the SDATA based on the time taken on the PBS in generating the SDATA message. In either case the PBS will ignore the CRETRY message since it would be either in Server Working or Client Working states. 5. The reception of the SDATA message on the PBC would move the PBC state machine to Client Working and this would result in synchronization of the state machines between the PBC and PBS. On 1/9/09 4:12 PM, "Stephen Hanna" wrote: > At IETF 73, I proposed that we change the PB-TNC > state machine to eliminate a problem. I would like > to verify that we have WG consensus for the solution > that I proposed. I think we had consensus in the > room but consensus on the mailing list is what > matters. Therefore, I have described the problem > and my proposed solution in this email. Please > review and comment on this. Whatever your opinion, > please respond to this email with an expression > of your opinion within two weeks (by 5 PM PST > on Friday, January 23). At that time, I will > declare consensus if we have it. > > The problem is more easily explained with the aid > of some diagrams. I suggest that you review the > slides on this topic that I used at IETF 73. They > are slides 30-44 in the slide deck available at > http://www.ietf.org/proceedings/08nov/slides/nea-0/nea-0.htm > The title of the first relevant slide is "PB-TNC > State Machine". > > In essence, the problem is that with the state machine > in draft-ietf-nea-pb-tnc-02.txt, it is possible for the > PBC and PBS to get stuck in different states, losing > synchronization. Say that the PBC sends CRETRY. Who > should send the next message? There's no guidance. > The PBS and PBC might both send the next message and > then they will each believe that the message they > receive from the other is a response to the message > they sent. It's a bad and messy situation. The easy > solutions don't work either, as described in the slides. > > At the meeting, I proposed a solution to the problem. > That was to alter the state machine to this one: > > CLOSE > +--------------------------------------+ > | | > +---------+ CRETRY +---------+ CLOSE | > CDATA | Server |<---------| Decided |-----------+ | > +------------>| Working |--------->| |--------+ | | > | +---------+ RESULT +---------+ SASYNC | | | > | ^ | | | |CASYNC | v v > | | | | +---------------|-----------+ | ======= > ======== | | +--------------+ | SASYNC v v " End " > " Init " CDATA or| | CASYNC | | +---------+ ======= > ======== CRETRY | |SDATA or v v | Server | ^ ^ > | | | v SRETRY +---------+ | Request | | | > | | SDATA +---------+ | Client | +---------+ | | > | +--------->| Client |<---| Request | | ^ | | > | | Working | SOK+---------+ | | | | > | +---------+ ^ ^ | | | | > | | | | CASYNC | | CASYNC | | | | > | | | +----------+ +--------+ | | | > | | | | | | > | | +------------------------------+ | | > | | SASYNC | | > | +-----------------------------------------+ | > | CLOSE | > | CLOSE | > +-----------------------------------------------------------+ > > This revised state machine adds several states to make sure > that the client and server always agree on whose turn it is > to send data after a CASYNC or SASYNC is sent. > > The main concern raised at IETF 73 was that this complicates > the state machine, adding two new states and one new PB-TNC > message type. That's true. However, I have wracked my brain > for a simpler solution that works and I haven't found one. > If someone else has a simpler solution, please speak up! > If not, I think we'll need to proceed with this one. It's > not bad. It's fairly simple, really. It just adds a bit > more complexity and that's never a good thing. > > Thanks, > > Steve > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jan 22 14:19:58 2009 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9059E3A6856; Thu, 22 Jan 2009 14:19:58 -0800 (PST) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936D53A6856 for ; Thu, 22 Jan 2009 14:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 0sUqp+vlgnSG for ; Thu, 22 Jan 2009 14:19:56 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6EBD83A67F5 for ; Thu, 22 Jan 2009 14:19:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,308,1231113600"; d="scan'208";a="60590826" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 22 Jan 2009 22:19:39 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n0MMJcYH012903; Thu, 22 Jan 2009 14:19:38 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n0MMJbVb012021; Thu, 22 Jan 2009 22:19:38 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 14:19:38 -0800 Received: from 171.69.75.173 ([171.69.75.173]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Jan 2009 22:19:04 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 22 Jan 2009 14:19:01 -0800 From: kaushik To: Stephen Hanna , Message-ID: Thread-Topic: [Nea] Proposed PB-TNC state machine changes Thread-Index: AclypcB2Q+y69IjkRMiGpE8j308WeAKOV9Z3AAATXwY= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 22 Jan 2009 22:19:38.0044 (UTC) FILETIME=[83602FC0:01C97CDF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8474; t=1232662778; x=1233526778; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20kaushik=20 |Subject:=20Re=3A=20[Nea]=20Proposed=20PB-TNC=20state=20mac hine=20changes |Sender:=20; bh=iDfBWX4AU1H2Qd3NESNjjzD1mYsUGCh/vq5cLO2ZejQ=; b=BzYtvFZw4BW4tRxh0fTcKjLPhJsnFl9yrvuGyxnbzgS31B7+gT7D4pM4yG CCqkbRkaf5dahYIkgaf06XuuE75rpKHtMhWixOBEr8Ld5FJvICxJ6k1Wmt3f EPQNrUDNb3; Authentication-Results: sj-dkim-4; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Nea] Proposed PB-TNC state machine changes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Ignore my previous message since it is not complete and got sent out inadvertently. I will send a complete message in a few minutes. On 1/22/09 2:16 PM, "kaushik" wrote: > Hi Steve, > > The proposed solution addresses the synchronization issues with the PB-TNC > state machine but introduces additional states and state transitions which > increase the overall complexity of the state machine as you have pointed out. > Here is an alternate that might be a simpler option > > The fundamental problem is that re-assessment can be initiated by either by > the Posture Broker Client or the Posture Broker Server and the state machine > on the PBS and PBC can get out of synch if the re-assessment messages are > generated at the same time and cross each other in transit. We can make a > simplifying assumption that we won't allow re-assessment to be triggered > during an assessment, i.e. Assessments will run to completion without being > interrupted. This would mean that CRETRY and SRERTY messages can only be sent > from the Decided state and that CRETRY & SRETRY messages sent during an > assessment, i.e. when the state is either Client Working or Server Working, > will be ignored. > > The updated State Machine would look like this > > > Receive > CRETRY or > SRETRY* SRETRY* > +--+ +----------------+ > | | | | > v | v | > +---------+ CRETRY +---------+ > CDATA | Server |<---------| Decided | CLOSE > +----------->| Working |--------->| |-------+ > | +---------+ RESULT +---------+ | > | ^ | | v > | | | +---------------------->======= > ======== | | CLOSE " End " > " Init " CDATA| |SDATA ======= > ======== | | ^ ^ > | | | v | | > | | SDATA +---------+ CLOSE | | > | +-------->| Client |----------------------+ | > | | Working | | > | +---------+ | > | | ^ Receive | > | | | CRETRY* | > | +--+ | > | CLOSE | > +--------------------------------------------------+ > > > The changes from the state machine in the -02 version of the draft include > > - CRETRY/SRETRY can only be sent from Decided state. > - CRERTY and SRETRY sent from the Decided state move the state machine to > Server Working state. > - CRETRY or SRETRY messages received in Server Working state are ignored > - CRETRY message received in Client Working state is ignored. > > Let's apply this state machine to a re-assessment scenario. > > 1. The state machine is in the Decided state and the Posture Broker Server > decides to initiate a re-assessment and sends a SRERTY and the state machine > on the PBS moves to the Server Working state. > > 3. The Posture Broker Client may at the exact same time decide to initiate a > re-assessment and send a CRETRY and that would move the state machine on the > PBC to the Server Working state. > 4. The PBS can receive the CRETRY from the PBC before or after it sends the > SDATA based on the time taken on the PBS in generating the SDATA message. In > either case the PBS will ignore the CRETRY message since it would be either in > Server Working or Client Working states. > 5. The reception of the SDATA message on the PBC would move the PBC state > machine to Client Working and this would result in synchronization of the > state machines between the PBC and PBS. > > > > > On 1/9/09 4:12 PM, "Stephen Hanna" wrote: > >> At IETF 73, I proposed that we change the PB-TNC >> state machine to eliminate a problem. I would like >> to verify that we have WG consensus for the solution >> that I proposed. I think we had consensus in the >> room but consensus on the mailing list is what >> matters. Therefore, I have described the problem >> and my proposed solution in this email. Please >> review and comment on this. Whatever your opinion, >> please respond to this email with an expression >> of your opinion within two weeks (by 5 PM PST >> on Friday, January 23). At that time, I will >> declare consensus if we have it. >> >> The problem is more easily explained with the aid >> of some diagrams. I suggest that you review the >> slides on this topic that I used at IETF 73. They >> are slides 30-44 in the slide deck available at >> http://www.ietf.org/proceedings/08nov/slides/nea-0/nea-0.htm >> The title of the first relevant slide is "PB-TNC >> State Machine". >> >> In essence, the problem is that with the state machine >> in draft-ietf-nea-pb-tnc-02.txt, it is possible for the >> PBC and PBS to get stuck in different states, losing >> synchronization. Say that the PBC sends CRETRY. Who >> should send the next message? There's no guidance. >> The PBS and PBC might both send the next message and >> then they will each believe that the message they >> receive from the other is a response to the message >> they sent. It's a bad and messy situation. The easy >> solutions don't work either, as described in the slides. >> >> At the meeting, I proposed a solution to the problem. >> That was to alter the state machine to this one: >> >> CLOSE >> +--------------------------------------+ >> | | >> +---------+ CRETRY +---------+ CLOSE | >> CDATA | Server |<---------| Decided |-----------+ | >> +------------>| Working |--------->| |--------+ | | >> | +---------+ RESULT +---------+ SASYNC | | | >> | ^ | | | |CASYNC | v v >> | | | | +---------------|-----------+ | ======= >> ======== | | +--------------+ | SASYNC v v " End " >> " Init " CDATA or| | CASYNC | | +---------+ ======= >> ======== CRETRY | |SDATA or v v | Server | ^ ^ >> | | | v SRETRY +---------+ | Request | | | >> | | SDATA +---------+ | Client | +---------+ | | >> | +--------->| Client |<---| Request | | ^ | | >> | | Working | SOK+---------+ | | | | >> | +---------+ ^ ^ | | | | >> | | | | CASYNC | | CASYNC | | | | >> | | | +----------+ +--------+ | | | >> | | | | | | >> | | +------------------------------+ | | >> | | SASYNC | | >> | +-----------------------------------------+ | >> | CLOSE | >> | CLOSE | >> +-----------------------------------------------------------+ >> >> This revised state machine adds several states to make sure >> that the client and server always agree on whose turn it is >> to send data after a CASYNC or SASYNC is sent. >> >> The main concern raised at IETF 73 was that this complicates >> the state machine, adding two new states and one new PB-TNC >> message type. That's true. However, I have wracked my brain >> for a simpler solution that works and I haven't found one. >> If someone else has a simpler solution, please speak up! >> If not, I think we'll need to proceed with this one. It's >> not bad. It's fairly simple, really. It just adds a bit >> more complexity and that's never a good thing. >> >> Thanks, >> >> Steve >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jan 22 14:34:18 2009 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D533A68F4; Thu, 22 Jan 2009 14:34:18 -0800 (PST) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464583A68F4 for ; Thu, 22 Jan 2009 14:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 a9qBAVXZgOIb for ; Thu, 22 Jan 2009 14:34:10 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E0D403A68EB for ; Thu, 22 Jan 2009 14:34:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,308,1231113600"; d="scan'208";a="234935616" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Jan 2009 22:33:54 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0MMXsn4001359; Thu, 22 Jan 2009 14:33:54 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0MMXsTG002699; Thu, 22 Jan 2009 22:33:54 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 14:33:54 -0800 Received: from 171.69.75.173 ([171.69.75.173]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Jan 2009 22:33:47 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 22 Jan 2009 14:33:45 -0800 From: kaushik To: Stephen Hanna , Message-ID: Thread-Topic: [Nea] Proposed PB-TNC state machine changes Thread-Index: AclypcB2Q+y69IjkRMiGpE8j308WeAKO7u9M In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 22 Jan 2009 22:33:54.0290 (UTC) FILETIME=[81BCF520:01C97CE1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8563; t=1232663634; x=1233527634; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20kaushik=20 |Subject:=20Re=3A=20[Nea]=20Proposed=20PB-TNC=20state=20mac hine=20changes |Sender:=20; bh=jLv4C/VLVhwJjUjU0+GmHjCPXbZc0QCkUGlcxFo0Vsg=; b=Y1onmaCF8bc26sZz/7hWOT3h7f8T8o7sCJ7AfA2DtEZ+zVzfv6PRLphzxY n7YZknjroJDkr0x1hPb+xw5f2ciUOtM7KQNUFCdmb2GCNEluRLRshiPORSBW XWKvgdk3c8q3EYHS9ksNkItCjicRK61sNFnZ00XrQa5NTn2SwRZ8E=; Authentication-Results: sj-dkim-1; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Nea] Proposed PB-TNC state machine changes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Hi Steve, The proposed solution addresses the synchronization issues with the PB-TNC state machine but introduces additional states and state transitions which increase the overall complexity of the state machine as you have pointed out. Here is an alternate that might be a simpler option The fundamental problem is that re-assessment can be initiated by either by the Posture Broker Client or the Posture Broker Server and the state machine on the PBS and PBC can get out of synch if the re-assessment messages are generated at the same time and cross each other in transit. We can make a simplifying assumption that we won't allow re-assessment to be triggered during an assessment, i.e. Assessments will run to completion without being interrupted. This would mean that CRETRY and SRERTY messages can only be sent from the Decided state and that CRETRY & SRETRY messages received during an assessment, (i.e. when the state is either Client Working or Server Working,) will be ignored. The updated State Machine would look like this Receive CRETRY or SRETRY SRETRY +--+ +----------------+ | | | | v | v | +---------+ CRETRY +---------+ CDATA | Server |<---------| Decided | CLOSE +----------->| Working |--------->| |-------+ | +---------+ RESULT +---------+ | | ^ | | v | | | +---------------------->======= ======== | | CLOSE " End " " Init " CDATA| |SDATA ======= ======== | | ^ ^ | | | v | | | | SDATA +---------+ CLOSE | | | +-------->| Client |----------------------+ | | | Working | | | +---------+ | | | ^ Receive | | | | CRETRY | | +--+ | | CLOSE | +--------------------------------------------------+ The changes from the state machine in the -02 version of the draft include - CRETRY/SRETRY can only be sent from Decided state. - CRERTY and SRETRY sent from the Decided state move the state machine to Server Working state. - CRETRY or SRETRY messages received in Server Working state are ignored - CRETRY message received in Client Working state is ignored. Let's apply this state machine to a re-assessment scenario where there could be potential synchronization issues. 1. The state machine is in the Decided state and the Posture Broker Server decides to initiate a re-assessment and sends a SRERTY and the state machine on the PBS moves to the Server Working state. 2. The Posture Broker Client may at the exact same time decide to initiate a re-assessment and send a CRETRY and that would move the state machine on the PBC to the Server Working state. 3. The PBS can decide to send a SDATA immediately which would move the state machine on the PBS to the Client Working state. 4. The PBC will receive the SRETRY message which it will ignore since it is in the Server Working state. 5. The PBS can receive the CRETRY from the PBC before or after it sends the SDATA based on the time taken on the PBS in generating the SDATA message. In either case the PBS will ignore the CRETRY message since it would be either in Server Working or Client Working states. 6. The reception of the SDATA message on the PBC would move the PBC state machine to Client Working and this would result in synchronization of the state machines between the PBC and PBS. This proposal seems to address most use cases that may result in an out-of-synch state machine between the PBC and PBS. We probably need closer scrutiny to ensure that this addresses all scenarios in question. Regards, kaushik On 1/9/09 4:12 PM, "Stephen Hanna" wrote: > At IETF 73, I proposed that we change the PB-TNC > state machine to eliminate a problem. I would like > to verify that we have WG consensus for the solution > that I proposed. I think we had consensus in the > room but consensus on the mailing list is what > matters. Therefore, I have described the problem > and my proposed solution in this email. Please > review and comment on this. Whatever your opinion, > please respond to this email with an expression > of your opinion within two weeks (by 5 PM PST > on Friday, January 23). At that time, I will > declare consensus if we have it. > > The problem is more easily explained with the aid > of some diagrams. I suggest that you review the > slides on this topic that I used at IETF 73. They > are slides 30-44 in the slide deck available at > http://www.ietf.org/proceedings/08nov/slides/nea-0/nea-0.htm > The title of the first relevant slide is "PB-TNC > State Machine". > > In essence, the problem is that with the state machine > in draft-ietf-nea-pb-tnc-02.txt, it is possible for the > PBC and PBS to get stuck in different states, losing > synchronization. Say that the PBC sends CRETRY. Who > should send the next message? There's no guidance. > The PBS and PBC might both send the next message and > then they will each believe that the message they > receive from the other is a response to the message > they sent. It's a bad and messy situation. The easy > solutions don't work either, as described in the slides. > > At the meeting, I proposed a solution to the problem. > That was to alter the state machine to this one: > > CLOSE > +--------------------------------------+ > | | > +---------+ CRETRY +---------+ CLOSE | > CDATA | Server |<---------| Decided |-----------+ | > +------------>| Working |--------->| |--------+ | | > | +---------+ RESULT +---------+ SASYNC | | | > | ^ | | | |CASYNC | v v > | | | | +---------------|-----------+ | ======= > ======== | | +--------------+ | SASYNC v v " End " > " Init " CDATA or| | CASYNC | | +---------+ ======= > ======== CRETRY | |SDATA or v v | Server | ^ ^ > | | | v SRETRY +---------+ | Request | | | > | | SDATA +---------+ | Client | +---------+ | | > | +--------->| Client |<---| Request | | ^ | | > | | Working | SOK+---------+ | | | | > | +---------+ ^ ^ | | | | > | | | | CASYNC | | CASYNC | | | | > | | | +----------+ +--------+ | | | > | | | | | | > | | +------------------------------+ | | > | | SASYNC | | > | +-----------------------------------------+ | > | CLOSE | > | CLOSE | > +-----------------------------------------------------------+ > > This revised state machine adds several states to make sure > that the client and server always agree on whose turn it is > to send data after a CASYNC or SASYNC is sent. > > The main concern raised at IETF 73 was that this complicates > the state machine, adding two new states and one new PB-TNC > message type. That's true. However, I have wracked my brain > for a simpler solution that works and I haven't found one. > If someone else has a simpler solution, please speak up! > If not, I think we'll need to proceed with this one. It's > not bad. It's fairly simple, really. It just adds a bit > more complexity and that's never a good thing. > > Thanks, > > Steve > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Jan 23 05:02:06 2009 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF463A68B8; Fri, 23 Jan 2009 05:02:06 -0800 (PST) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7363A68B8 for ; Fri, 23 Jan 2009 05:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 bZwDzc7BZe2G for ; Fri, 23 Jan 2009 05:02:03 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 48ED23A686C for ; Fri, 23 Jan 2009 05:02:03 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSXm/uiFamtwlK+bPlL9Cia0Rco7FaYSF@postini.com; Fri, 23 Jan 2009 05:01:47 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Fri, 23 Jan 2009 04:58:29 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jan 2009 04:58:29 -0800 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jan 2009 04:58:29 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2009 07:58:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Jan 2009 07:58:26 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Proposed PB-TNC state machine changes Thread-Index: AclypcB2Q+y69IjkRMiGpE8j308WeAKO7u9MAB3o/gA= References: From: Stephen Hanna To: "kaushik" , X-OriginalArrivalTime: 23 Jan 2009 12:58:28.0200 (UTC) FILETIME=[48FF7680:01C97D5A] Subject: Re: [Nea] Proposed PB-TNC state machine changes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Thanks, Kaushik. I like this idea! I was always troubled by the increased complexity of the last proposal. Since this is a substantial change from the previous proposal, let's extend the discussion and consensus check for another two weeks (until February 6). Folks, please review and comment on this proposal. As Kaushik points out, this does reduce the flexibility of the NEA system somewhat (requiring assessments to proceed to completion before they can be restarted). However, the benefits in simplicity are substantial. Greater simplicity generally leads to better security, reliability, and ease of implementation and adoption so it's definitely a good thing! So please comment on this proposal and whether you are comfortable with it. Thanks, Steve > -----Original Message----- > From: kaushik [mailto:kaushik@cisco.com] > Sent: Thursday, January 22, 2009 5:34 PM > To: Stephen Hanna; nea@ietf.org > Subject: Re: [Nea] Proposed PB-TNC state machine changes > > Hi Steve, > > The proposed solution addresses the synchronization issues > with the PB-TNC > state machine but introduces additional states and state > transitions which > increase the overall complexity of the state machine as you > have pointed > out. Here is an alternate that might be a simpler option > > The fundamental problem is that re-assessment can be > initiated by either by > the Posture Broker Client or the Posture Broker Server and > the state machine > on the PBS and PBC can get out of synch if the re-assessment > messages are > generated at the same time and cross each other in transit. > > We can make a simplifying assumption that we won't allow > re-assessment to be > triggered during an assessment, i.e. Assessments will run to > completion > without being interrupted. This would mean that CRETRY and > SRERTY messages > can only be sent from the Decided state and that CRETRY & > SRETRY messages > received during an assessment, (i.e. when the state is either > Client Working > or Server Working,) will be ignored. > > The updated State Machine would look like this > > > Receive > CRETRY or > SRETRY SRETRY > +--+ +----------------+ > | | | | > v | v | > +---------+ CRETRY +---------+ > CDATA | Server |<---------| Decided | CLOSE > +----------->| Working |--------->| |-------+ > | +---------+ RESULT +---------+ | > | ^ | | v > | | | +---------------------->======= > ======== | | CLOSE " End " > " Init " CDATA| |SDATA ======= > ======== | | ^ ^ > | | | v | | > | | SDATA +---------+ CLOSE | | > | +-------->| Client |----------------------+ | > | | Working | | > | +---------+ | > | | ^ Receive | > | | | CRETRY | > | +--+ | > | CLOSE | > +--------------------------------------------------+ > > > The changes from the state machine in the -02 version of the > draft include > > - CRETRY/SRETRY can only be sent from Decided state. > - CRERTY and SRETRY sent from the Decided state move the > state machine to > Server Working state. > - CRETRY or SRETRY messages received in Server Working state > are ignored > - CRETRY message received in Client Working state is ignored. > > Let's apply this state machine to a re-assessment scenario > where there could > be potential synchronization issues. > > 1. The state machine is in the Decided state and the Posture > Broker Server > decides to initiate a re-assessment and sends a SRERTY and > the state machine > on the PBS moves to the Server Working state. > 2. The Posture Broker Client may at the exact same time > decide to initiate a > re-assessment and send a CRETRY and that would move the state > machine on the > PBC to the Server Working state. > 3. The PBS can decide to send a SDATA immediately which would > move the state > machine on the PBS to the Client Working state. > 4. The PBC will receive the SRETRY message which it will > ignore since it is > in the Server Working state. > 5. The PBS can receive the CRETRY from the PBC before or > after it sends the > SDATA based on the time taken on the PBS in generating the > SDATA message. In > either case the PBS will ignore the CRETRY message since it > would be either > in Server Working or Client Working states. > 6. The reception of the SDATA message on the PBC would move > the PBC state > machine to Client Working and this would result in > synchronization of the > state machines between the PBC and PBS. > > This proposal seems to address most use cases that may result in an > out-of-synch state machine between the PBC and PBS. We > probably need closer > scrutiny to ensure that this addresses all scenarios in question. > > Regards, > kaushik > > On 1/9/09 4:12 PM, "Stephen Hanna" wrote: > > > At IETF 73, I proposed that we change the PB-TNC > > state machine to eliminate a problem. I would like > > to verify that we have WG consensus for the solution > > that I proposed. I think we had consensus in the > > room but consensus on the mailing list is what > > matters. Therefore, I have described the problem > > and my proposed solution in this email. Please > > review and comment on this. Whatever your opinion, > > please respond to this email with an expression > > of your opinion within two weeks (by 5 PM PST > > on Friday, January 23). At that time, I will > > declare consensus if we have it. > > > > The problem is more easily explained with the aid > > of some diagrams. I suggest that you review the > > slides on this topic that I used at IETF 73. They > > are slides 30-44 in the slide deck available at > > http://www.ietf.org/proceedings/08nov/slides/nea-0/nea-0.htm > > The title of the first relevant slide is "PB-TNC > > State Machine". > > > > In essence, the problem is that with the state machine > > in draft-ietf-nea-pb-tnc-02.txt, it is possible for the > > PBC and PBS to get stuck in different states, losing > > synchronization. Say that the PBC sends CRETRY. Who > > should send the next message? There's no guidance. > > The PBS and PBC might both send the next message and > > then they will each believe that the message they > > receive from the other is a response to the message > > they sent. It's a bad and messy situation. The easy > > solutions don't work either, as described in the slides. > > > > At the meeting, I proposed a solution to the problem. > > That was to alter the state machine to this one: > > > > CLOSE > > +--------------------------------------+ > > | | > > +---------+ CRETRY +---------+ CLOSE | > > CDATA | Server |<---------| Decided |-----------+ | > > +------------>| Working |--------->| |--------+ | | > > | +---------+ RESULT +---------+ SASYNC | | | > > | ^ | | | |CASYNC | v v > > | | | | +---------------|-----------+ | ======= > > ======== | | +--------------+ | SASYNC v v " End " > > " Init " CDATA or| | CASYNC | | +---------+ ======= > > ======== CRETRY | |SDATA or v v | Server | ^ ^ > > | | | v SRETRY +---------+ | Request | | | > > | | SDATA +---------+ | Client | +---------+ | | > > | +--------->| Client |<---| Request | | ^ | | > > | | Working | SOK+---------+ | | | | > > | +---------+ ^ ^ | | | | > > | | | | CASYNC | | CASYNC | | | | > > | | | +----------+ +--------+ | | | > > | | | | | | > > | | +------------------------------+ | | > > | | SASYNC | | > > | +-----------------------------------------+ | > > | CLOSE | > > | CLOSE | > > +-----------------------------------------------------------+ > > > > This revised state machine adds several states to make sure > > that the client and server always agree on whose turn it is > > to send data after a CASYNC or SASYNC is sent. > > > > The main concern raised at IETF 73 was that this complicates > > the state machine, adding two new states and one new PB-TNC > > message type. That's true. However, I have wracked my brain > > for a simpler solution that works and I haven't found one. > > If someone else has a simpler solution, please speak up! > > If not, I think we'll need to proceed with this one. It's > > not bad. It's fairly simple, really. It just adds a bit > > more complexity and that's never a good thing. > > > > Thanks, > > > > Steve > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www.ietf.org/mailman/listinfo/nea > > _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea