From shanna@juniper.net Mon Feb 9 07:13:11 2009 Return-Path: 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 0EA7A3A67E5 for ; Mon, 9 Feb 2009 07:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 JVZsPkKAuZ6v for ; Mon, 9 Feb 2009 07:13:09 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 93A353A687C for ; Mon, 9 Feb 2009 07:13:09 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSZBICoHq27GEJlNcs3fYMvWCdsPVJiGH@postini.com; Mon, 09 Feb 2009 07:13:15 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, 9 Feb 2009 06:55:35 -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, 9 Feb 2009 06:55:34 -0800 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 06:55:34 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 09:55:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Feb 2009 09:55:32 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Proposed PB-TNC state machine changes Thread-Index: AclypcB2Q+y69IjkRMiGpE8j308WeAKO7u9MAB3o/gADWy4RgA== References: From: Stephen Hanna To: X-OriginalArrivalTime: 09 Feb 2009 14:55:33.0691 (UTC) FILETIME=[758A10B0:01C98AC6] 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: , X-List-Received-Date: Mon, 09 Feb 2009 15:13:11 -0000 I haven't seen any comments on this topic other than Kaushik's and mine. I won't say that's WG consensus but there seems to be no objection to making this change. Since the state machine in draft-ietf-nea-pb-tnc-02.txt has a serious known bug, let's make this change. I think this is the last open issue so I'd like to ask our editors (including myself) to please prepare a -03 revision. This should be ready for WG Last Call. Thanks, Steve > -----Original Message----- > From: Stephen Hanna=20 > Sent: Friday, January 23, 2009 7:58 AM > To: 'kaushik'; nea@ietf.org > Subject: RE: [Nea] Proposed PB-TNC state machine changes >=20 > Thanks, Kaushik. I like this idea! I was always troubled > by the increased complexity of the last proposal. >=20 > 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). >=20 > 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. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: kaushik [mailto:kaushik@cisco.com]=20 > > Sent: Thursday, January 22, 2009 5:34 PM > > To: Stephen Hanna; nea@ietf.org > > Subject: Re: [Nea] Proposed PB-TNC state machine changes > >=20 > > Hi Steve, > >=20 > > The proposed solution addresses the synchronization issues=20 > > with the PB-TNC > > state machine but introduces additional states and state=20 > > transitions which > > increase the overall complexity of the state machine as you=20 > > have pointed > > out. Here is an alternate that might be a simpler option > >=20 > > The fundamental problem is that re-assessment can be=20 > > initiated by either by > > the Posture Broker Client or the Posture Broker Server and=20 > > the state machine > > on the PBS and PBC can get out of synch if the re-assessment=20 > > messages are > > generated at the same time and cross each other in transit. > >=20 > > We can make a simplifying assumption that we won't allow=20 > > re-assessment to be > > triggered during an assessment, i.e. Assessments will run to=20 > > completion > > without being interrupted. This would mean that CRETRY and=20 > > SRERTY messages > > can only be sent from the Decided state and that CRETRY &=20 > > SRETRY messages > > received during an assessment, (i.e. when the state is either=20 > > Client Working > > or Server Working,) will be ignored. > >=20 > > The updated State Machine would look like this > >=20 > >=20 > > Receive > > CRETRY or > > SRETRY SRETRY > > +--+ +----------------+ > > | | | | > > v | v | > > +---------+ CRETRY +---------+ > > CDATA | Server |<---------| Decided | CLOSE > > +----------->| Working |--------->| |-------+ > > | +---------+ RESULT +---------+ | > > | ^ | | v > > | | | = +---------------------->=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D | | CLOSE = " End " > > " Init " CDATA| |SDATA = =3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D | | = ^ ^ > > | | | v | | > > | | SDATA +---------+ CLOSE | | > > | +-------->| Client |----------------------+ | > > | | Working | | > > | +---------+ | > > | | ^ Receive | > > | | | CRETRY | > > | +--+ | > > | CLOSE | > > +--------------------------------------------------+ > >=20 > >=20 > > The changes from the state machine in the -02 version of the=20 > > draft include > >=20 > > - CRETRY/SRETRY can only be sent from Decided state. > > - CRERTY and SRETRY sent from the Decided state move the=20 > > state machine to > > Server Working state. > > - CRETRY or SRETRY messages received in Server Working state=20 > > are ignored > > - CRETRY message received in Client Working state is ignored. > >=20 > > Let's apply this state machine to a re-assessment scenario=20 > > where there could > > be potential synchronization issues. > >=20 > > 1. The state machine is in the Decided state and the Posture=20 > > Broker Server > > decides to initiate a re-assessment and sends a SRERTY and=20 > > the state machine > > on the PBS moves to the Server Working state. > > 2. The Posture Broker Client may at the exact same time=20 > > decide to initiate a > > re-assessment and send a CRETRY and that would move the state=20 > > machine on the > > PBC to the Server Working state. > > 3. The PBS can decide to send a SDATA immediately which would=20 > > move the state > > machine on the PBS to the Client Working state. > > 4. The PBC will receive the SRETRY message which it will=20 > > ignore since it is > > in the Server Working state. > > 5. The PBS can receive the CRETRY from the PBC before or=20 > > after it sends the > > SDATA based on the time taken on the PBS in generating the=20 > > SDATA message. In > > either case the PBS will ignore the CRETRY message since it=20 > > would be either > > in Server Working or Client Working states. > > 6. The reception of the SDATA message on the PBC would move=20 > > the PBC state > > machine to Client Working and this would result in=20 > > synchronization of the > > state machines between the PBC and PBS. > >=20 > > This proposal seems to address most use cases that may result in an > > out-of-synch state machine between the PBC and PBS. We=20 > > probably need closer > > scrutiny to ensure that this addresses all scenarios in question. > >=20 > > Regards, > > kaushik > >=20 > > On 1/9/09 4:12 PM, "Stephen Hanna" wrote: > >=20 > > > 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. > > >=20 > > > 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". > > >=20 > > > 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. > > >=20 > > > At the meeting, I proposed a solution to the problem. > > > That was to alter the state machine to this one: > > >=20 > > > CLOSE > > > +--------------------------------------+ > > > | | > > > +---------+ CRETRY +---------+ CLOSE | > > > CDATA | Server |<---------| Decided |-----------+ | > > > +------------>| Working |--------->| |--------+ | | > > > | +---------+ RESULT +---------+ SASYNC | | | > > > | ^ | | | |CASYNC | v v > > > | | | | +---------------|-----------+ | = =3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D | | +--------------+ | SASYNC = v v " End " > > > " Init " CDATA or| | CASYNC | | +---------+ = =3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D CRETRY | |SDATA or v v | = Server | ^ ^ > > > | | | v SRETRY +---------+ | Request | | | > > > | | SDATA +---------+ | Client | +---------+ | | > > > | +--------->| Client |<---| Request | | ^ | | > > > | | Working | SOK+---------+ | | | | > > > | +---------+ ^ ^ | | | | > > > | | | | CASYNC | | CASYNC | | | | > > > | | | +----------+ +--------+ | | | > > > | | | | | | > > > | | +------------------------------+ | | > > > | | SASYNC | | > > > | +-----------------------------------------+ | > > > | CLOSE | > > > | CLOSE | > > > +-----------------------------------------------------------+ > > >=20 > > > 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. > > >=20 > > > 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. > > >=20 > > > Thanks, > > >=20 > > > Steve > > > _______________________________________________ > > > Nea mailing list > > > Nea@ietf.org > > > https://www.ietf.org/mailman/listinfo/nea > >=20 > >=20